In his essay titled, "Java's Cover", Paul Graham
explains why he thinks Java is a "stinker".
Although some of the points made are valid,
there are many misconceptions that are unfair or outright
wrong, and need to be corrected. More importantly,
Dr. Graham seems to miss the real value propostion of
Java as a language and platform.
A few weeks ago, in his Artima blog, my buddy John McClain told us about an
interesting essay by Paul Graham (located at
in which hackers (in the true definition of "hacker") are compared to painters.
Well, anything John tells me to read, I read; because John has never steered
me wrong. Heck, if it weren't for John, I'd probably never read Slashdot.
Anyway, after reading the essay, I was impressed enough not only with the
content of the essay, but also with the style and layout of Dr. Graham's web
site, that I started rooting around the site; looking for other interesting
things to read that might be there. Now, anyone who knows me is probably
thinking, "That must be some site!"
You see, I've always been more of a 'pencil-and-paper' Math geek kinda guy,
rather than a point-and-click-surf-the-web kinda guy. I guess I probably
wouldn't fit in with the hackers. Although, like a lot of hackers, I've taken
only one CS course in my life. That was in high school, a long time ago.
I was so turned off by the processes and formalisms (like flow-charting)
that were imposed on us that I swore I'd never take another one. But I
do like to think long and hard about a program, and even make rough design
sketches (in pencil of course), before I start pounding on the keyboard.
And according to the author, that makes me not a hacker; I think he's
probably right. I guess that makes me more of a ... well, a mathematician,
posing as programmer.
And the author is right about another thing in that first essay:
mathematicians do think they're smarter than everyone else. And this used
to drive me crazy in grad school. With a few notable exceptions, most of
my professors and peers in grad school had quite a high opinion of their
own abilities. I used to wonder, "How can people who wear their pants up
around their chest possibly be smarter than the rest of us?" Of course,
that kind of attitude always got me in trouble with my professors and
office mates. So I guess I was a misfit in the world of mathematics, just
as I seem to be a misfit in the world of computers ... but I digress.
So, I don't surf that often, unless it's in the ocean. And I've not been
known to root around anyone's web site, unless it's for free (as in free
speech) software or free music; you know, the important stuff .... but
again, I digress. The point is, the quality of the first essay, and the
quality of the site where it's hosted, caused me to discover another
essay by Paul Graham that people who visit Artima might find interesting
as well. That essay is titled, "Java's Cover", and is located at,
Like the first essay, this one is very well written, and makes a lot of
valid points that really hit the nail on the head. But there were some things
the author said not only about Java, but also about Sun in general and its
handling of Java in particular, that I happen to disagree with. At first,
I thought I'd send Dr. Graham an e-mail containing the appropriate
corrections. "Yeah", I thought. "He'll be so grateful that someone he's
never met is nice enough to tell him all the things he's wrong about.
Yeah, that's the ticket." But then in a brief moment of sanity I realized
what an idiot I was. And besides, I'd never be able to bring myself to hit
the 'send' button anyway; too much of a coward. So I was faced with a small
dilemma. I felt that it was important that someone stick up for Java and
Sun, but I wanted to remain somewhat anonymous. And then it came to me.
I figured I could write up a reply and post it at Artima; who's going to
read what I have to say there anyway? And if anyone does happen to stumble
across my ramblings, I'm among friends, right? .... right!? So here goes
Dr. Graham introduces his essay with a caveat in which he says he's not
really writing about Java, but about hacker's radar. If that's true, then
I suppose my comments below should be directed more at the misconceptions
held by the hackers, rather than the author. But when you read the essay I
think you'll probably come to the same conclusion I did: even though the
author makes claims to the contrary, he himself has some serious, critical
biases against both Java and Sun.
Some of Dr. Graham's criticisms of Java in particular, and Sun in general,
are actually well-founded. And I'll try to point them out; hopefully,
without getting myself into too much trouble with my employer. Fortunately
for me, Sun has always been - and continues to be - an "engineer's company",
as opposed to one of those companies where fear-and-loathing of management
runs rampant. This has allowed for quite a bit of self-examination and even
self-criticism. The reason for this, I believe, is because of leaders like
Scott McNealy and Bill Joy. Because of people like McNealy and Joy, as
well as other technical leaders like Rob Gingell, critical review without
retribution has always been part of the culture at Sun.
Prior to joining the company, I always had a lot of respect for Sun. And
I figured that upon joining Sun some of that respect would decrease once
I saw what goes on behind closed doors. This is fairly typical of most
successful companies; everything the public sees generally has some kind
of "spin" on it. So I was pleasantly surprised when I joined Sun and found
that for the most part, its a very well-intentioned company that's just
trying to build good stuff; where the company will win or lose based on
the merits of the stuff we create, not on "out-marketing" the competition.
Of course, as Sun has grown, it certainly has acquired its share of
self-serving, political "weenies" (the technical term), but those folks
seem to be more than offset by the many good people still at Sun. Which
brings me to my first reply to Dr. Graham's essay.
In the essay, Dr. Graham seems to credit all of Java's popularity on nothing
but an aggressive marketing strategy that's laced with ulterior motives
marked by a desperation caused by the current economy. Consider some of
the following reasons Dr. Graham gives for Java being -- as he puts it -- a
"It has to be energetically hyped."
"It has ulterior motives. ... the reason we hear about Java all the
time is not because it has something to say about programming
languages. We hear about Java as part of a plan by Sun to undermine
"Java .... happens to be controlled by a giant company. So the
language is likely to have the same drab clunkiness as anything
else that comes out of a big company."
"Its daddy is in a pinch. ... If Sun runs into trouble, they could
drag Java down with them."
The statements above seem to paint the following picture:
Java is so big, bad, clunky, and useless that it has to be "sold"
to developers like a good-for-nothing used car to an unsuspecting
Sun is some kind of huge, evil company that has complete control over
Java and its future; and has devised some kind of sinister plot to
use Java to destroy its competitors.
I think Dr. Graham has given Sun way too much credit. First, Dr. Graham
doesn't seem to understand that there are other companies (IBM and BEA
just to name two) that exert an incredible amount of influence and control
over Java. I know this from personal experience. My group's work has been
directly and negatively affected by that influence; trust me, it's quite
formidable. These companies make a lot more money off of Java than Sun does.
They also are responsible for quite a bit of the hype (as well as the
"clunkiness") that Dr. Graham is blaming on Sun. Granted, Sun has
hyped -- and continues to hype -- Java, but to place all the blame on
Sun is simply unfair. And then to say that Java has nothing to say, and
that Sun is simply using it to undermine Microsoft is just plain ludicrous.
Such a statement contains the same sort of arrogance that Dr. Graham seems
to be crediting to Sun.
To support my rebuttal above, I think it's important that I say a few words
about Scott McNealy. No matter what you may think about Scott McNealy and his
antics in the media, my take on him is that he really is a true leader who
believes deeply in technology. He's definitely not your typical CEO who just
wants to make a lot of money while destroying his competitors along the way.
I truly believe he wants to create great technology. And I believe he thinks
there's more than enough money to go around for other companies who also want
to create great technology.
At JavaOne 2002, I was listening to a keynote given by McNealy. I was sitting
next to a colleague who had never heard him speak before. Her prior impression
of him was the typical one: brash, anti-MicroSoft, a lot of hype, a typical
CEO. After listening to the keynote, she turned to me and said, "Wow, he
really wants to save the world, doesn't he?" And I thought, "She's right.
He does seem to care more about good technology than about just making
Unlike other CEO's I've encountered, McNealy seems to understand that he's
not smarter than everyone else; he actually listens to the techies he has
advising him (people like Bill Joy and Rob Gingell). Unfortunately, as
companies grow, it gets harder and harder to innovate because "the Bozo factor"
begins to take effect (a term coined by McNealy himself). The Bozo factor
occurs when a company grows so fast it can't be as selective as it could
be in the early days. Mediocre employees, exemplified by "weenie" middle
managers, begin to leave the sinking ships of failing competitors looking
for a safe place to hide and avoid risk. As more and more of these
well-meaning but misguided souls join the successful company, progress
and innovation becomes more difficult to achieve because information
flow is prevented in an effort to avoid risk at all costs.
This is why I am fairly certain that Sparc and Java would not exist today if
they had been proposed at a company like IBM or HP or Xerox. At that time,
those companies were much larger than Sun, and were infested with folks
unwilling to risk violating the status quo. Paraphrasing Dr. Graham in his
first essay noted above, '... startups win ... big companies want to minimize
risk at all costs'. As Dr. Graham says, "Big companies win by sucking less
than other big companies." So I believe Dr. Graham would concur with my
supposition about Sparc and Java. And I think it's important to remember that
when Sparc was proposed, and certainly when Java was proposed, Sun was not
a startup; although McNealy continued to instill the startup mentality.
Oh, and it's not just large companies that lack vision; people in the media
seem to suffer from risk aversion as well. I can still remember the
dire predictions of doom for Sun in the "San Jose Mercury News" that were
motivated by Sun's decision to switch to Sparc.
Which brings me to Dr. Graham's criticisms of Java itself. Although Dr.
Graham might agree with me that Java could not have survived -- and certainly
could not have thrived -- at many other companies other than Sun, he
certainly doesn't share my respect for the technology as a programming
language or a platform. Before I respond to some of his criticisms of Java
though, I should probably say a few words about my own views on programming
languages; so that you can better put my words into perspective.
As I said above, I'm certainly not a hacker. I have a lot of respect for
the hacker culture; and I wish I were good enough to be a part of that
culture ... sigh ... but I know the limitations of my own abilities. But
it's important for you to understand that I have programmed; whether it
was good or bad programming is a matter of opinion. Additionally, I'm not
a "software snob". You probably already know what I mean by that term. A
software snob is one of those people who think their way is the only way;
they're generally arrogant and condescending, and they almost always dismiss
anyone who doesn't share their "religious" views. Although it could be a
particular technique or pattern for solving a problem, software snobs are
often characterized by a belief in a particular programming language. The
first time I encountered true software snobbery was around the time OO
techniques in general, and C++ in particular, were becoming popular with
the "unwashed" masses. Prior to that, it just seemed like random encounters
with arrogant, condescending people (although in Math grad school, such
encounters were far more common than random).
I can remember sitting in design reviews for systems that had hard real-time
signal processing requirements. Because the system was a large, distributed
system consisting of components involved in non-real-time resource allocation
and command and control, as well as real-time signal acquisition and analysis,
some parts were written in assembler, some were written in C and C++, and
some were written in (gasp!) Ada. The assembler and C folks were hard core
signal processors -- FFT's, power spectrums, low and high pass filters,
sampling, aliasing, that sort of thing. Although the C++ and Ada folks would
gang up on the signal processors ("Assembler and C is for neanderthals. Our
methodologies are better than yours."), the real fun was in watching the
religious wars between the C++ folks and the Ada folks ("My language is
better than yours. You idiot! That's not object oriented!")
In the end, all of the posturing and all of the animosity was just so
unnecessary. The components that required assembler had incredibly high
throughputs that could be achieved only with specially tuned assembler code.
The C and C++ components didn't need assembler, but had certain requirements
that Ada couldn't handle. And everything else had to be written in Ada
because the customer required it. (Yes, I agree with Dr. Graham. The fact
that the DoD likes Java has me a bit concerned too). So what was there to
argue about? I can't tell you how many meetings I sat through listening to
people whining about the inadequacies of the others' language of choice. It
was a very interesting study in human nature. People seem to defend
their turf and respective belief systems like they would their own
children from an attacker.
Looking back on that experience and my participation in the project, I
recall that I wasn't real particular about what language I was using. I was
always much more interested in the problem that was being solved, and how
to solve it. My interest in the language that was used to implement the
solution was restricted to whether or not the language could support the
solution. So I guess you could call me a "software slut" rather than a
snob. I'd program in anything as long as it helped solve the problem.
Fortunately for me, I had to program in all four of the languages used
on that project. Except for C, I had never previously programmed in any
of them, and I found all four to be interesting and valuable. They each
had their positive and negative aspects, and they each taught me something
that I didn't know previously.
So when all is said and done, my interest has always been in the problem
at hand, not the language. Of course, it's great if the language you choose
(or more likely, that's been chosen for you) is a language that you already
know and love, but since that doesn't happen very often, I find that I
have a lot less stress than the people who constantly grouse about being
forced to compromise their artistic integrity. Which leads me to the whole
point of this posting. Dr. Graham has some serious criticisms of Java
as a language; some of them are deserved. But most of his criticisms sound
a lot like the sort of closed-minded snobbery I experienced on the project
I've programmed in a lot of the languages Dr. Graham claims were developed
for the masses (the so-called "mediocre programmers"); languages like Fortran,
C++, and (gasp!) Ada. I've also programmed in a couple of the languages that
Dr. Graham calls the "good languages"; C and Perl for example. While I have
to admit that I liked programming in both C and Perl, and I can see why
there might be some religious fervor for each, I'm not sure I would
(or could) use either of them to do what I'm doing now with Java. You see,
I need to move objects around the network.
Reading Dr. Graham's essay made me think back on all the projects I've
worked on, the problems those projects addressed, and the languages used
to implement solutions to the problems. This caused me to come to the
following realization. Throughout my career the languages I used always
changed from project to project, but the problem being solved has always
fundamentally remained the same. Whether the problem domain was command
and control, signal acquisition and analysis, transport and robotic control,
telecom middleware, etc., the problem ultimately was always a distributed
problem that required disparate components on remote systems to communicate
and cooperate with each other. Being able to move objects allows one to
better build such systems. And when building such systems, I also need
distributed agreement and distributed security. Java either provides
these things for me, or it allows me to provide them.
I realize that this aspect of Java might get lost in the marketing hype
surrounding Java; especially when all that one looks at is the cover. And
I have to admit that after attending the most recent JavaOne that it appears
that Dr. Graham is right about another thing. The "committee" Dr. Graham
refers to that controls Java from Sun's perspective has decided to
de-emphasize the code mobility capabilities of Java and instead add
"features" that will make it even more attractive to the masses. (By the way,
that so-called "committee" is a lot smaller than you'd expect. Some might
even say that it's really just one or two people. Of course, this doesn't
include all the people from outside of Sun that are driving Java).
Nevertheless, when you open the "book" and look inside, you see that
(in my opinion of course) Java's true strength lies in its ability
to move code; not in generics or meta tags, or built-in XML parsers, etc.
For years the hype around Java was "Write Once, Run Anywhere" (WORA); for
some it still is. And it was a simple and easy-to-understand message. But
people -- even some of Sun's own people -- didn't see what WORA actually
brought to the table. WORA allows for code mobility because it places
the agreement at the appropriate place in the system -- in
the language and in the interfaces you define.
A lot of people (again, even some Sun people) seem to think that the term
"code mobility" means that you write and test an application on one system,
and then zip it up, "walk it over" to another system, install it, and run
it on that other system. They think that that is what WORA brings to the
table. But in my opinion, that is not what code mobility is. To me, code
mobility is when an application already running on one system can receive
and run (securely and without prior knowledge other than interfaces) another
piece of code from (a proxy to) an application that's running somewhere
else. This, in my opinion, is what makes Java special. And this is why I
use (and will continue to use) Java.
And so it's important to be careful when judging a book or language by its
cover. Since a lot of people have no interest in problems in distributed
computing, they overlook this important aspect of Java. They view Java as
"just another language", which may or may not stand up well against their
particular language of choice, depending on the type of problem they're
trying to solve. I happen to have a particular interest in distributed
computing. I believe Java addresses that problem better than any other
language I've used so far. I don't use Java because of marketing or hype
or because it's "pseudo-hip" or because everyone else is using it. I use
Java because it allows me to move code.
Dr. Graham says, "From what little I know about Java, there seem to be
a lot of protocols for doing things." On the contrary, Java actually
allows us to free ourselves from such dependencies (see "The End of Protocols"
by Jim Waldo, at
As I said above, whenever a distributed system is defined, generally some
form of agreement must occur some place in the system. It might be that your
component and some remote component must agree on the structure and meaning
of a certain set of messages that are passed back and forth. Or it might
mean that a special XML parser has to be defined and installed on every
node in the system. And it might mean that in either case, when a change
is necessary, a new parser must be installed everywhere; or every component
might need to be brought down, re-compiled, and re-started to accommodate
new messages. I think the strength of Java is that it allows the placement
of the agreement in such a system to be in what I consider to be the
right place. The agreement doesn't have to be in the message protocols
or the parsers. Java allows the agreement to be in the language itself and
Once you agree that your components are written in Java, and you agree upon,
and define, your remote interfaces, everything else is local and private;
all communication protocols are private details of the implementation. You
don't have to get any third parties to agree to the meaning or structure
of your messages, or to install any parsers; they only have to agree to
use Java, and to honor the contract reflected in the interfaces that make
up the system.
And so this is why I think Java is not just another language. This is what
I think is special about it; what its real value proposition is. And why it's
not just for the masses. Java provides a well-defined system for contractual
agreement that enables the movement of code; ultimately resulting in an
elegant mechanism for building truly distributed systems. As John McClain
puts it, "Java allows you to move objects onto the network."
Well, if you've made it this far, then I have to admit, I'm impressed.
Most people, walk away after the first or second sentence. Although
I seem incapable of making my points in any kind of short, concise, or
coherent manner, I guess the main points I'm trying to make are that Sun
really isn't an evil company, Java really isn't a bad language that's
good only for the "dumb programmer", and the language one uses is just
a tool used to solve a problem. The language isn't the end in and of
itself; it shouldn't take precedence over the problem it's intended to
Just because you love a particular language, because it has all the
"right" features, and it's got the right amount of elegance, deserving
of a programmer of your stature, it doesn't mean that that language is
appropriate for any and all problems. If I'm a carpenter who needs to
cut off the end of a board, I certainly can use my favorite hammer
to pound on the end of the board until it breaks off. But that particular
problem would probably be better solved if I used my saw; even though
I really like my hammer a lot more than my saw, and even though I usually
use my hammer to solve most of my problems. Sometimes my saw is the
appropriate tool to use to solve the problem at hand.
So I would ask Dr. Graham not to write off Java so quickly. I believe
it does have value; it does address certain problems better than most other
languages. It just may be that he doesn't know what those problems are.
And it may be that IBM and BEA (and even Sun) doesn't know what those
problems are either. But a boy can dream, can't he?
Not sure whether I count as a real hacker or not, but I can offer a view on why hackers don't always like Java. <p> It's not (much) to do with Sun or Scott McNealy. I find it reassuring that Sun is still run by technical types. <p> A major reason is that Java, as in the complete language, virtual machine, and class library promoted by Sun, <b>is</b> for language snobs. Take your signal processing example: <i> Because the system was a large, distributed system consisting of components involved in non-real-time resource allocation and command and control, as well as real-time signal acquisition and analysis, some parts were written in assembler, some were written in C and C++, and some were written in (gasp!) Ada. <br> ... <br> Looking back on that experience and my participation in the project, I recall that I wasn't real particular about what language I was using. I was always much more interested in the problem that was being solved, and how to solve it. <i> <p> Exactly. Good hackers still indulge in language wars, as demonstrated by Paul Graham, but they're much more good natured and thoughtful about it than most. <p> Now comes the contradiction of your message. After this fine example of multi-language system development and how it couldn't really be done any other way, you move on to distributed system design: <i> I think the strength of Java is that it allows the placement of the agreement in such a system to be in what I consider to be the right place. The agreement doesn't have to be in the message protocols or the parsers. Java allows the agreement to be in the language itself and the interfaces.
Once you agree that your components are written in Java, <br> ... </i> <p> This is where hackers get uppity. Hey, suppose I have hard realtime requirements too? What about all this Python code that runs the user interface? <p> Java, as currently shipped by Sun, is for language snobs. Use our language, our class library, our virtual machine. We have all the answers. <p> What about the JNI? Sun have made it unnecessarily difficult and complex IMHO: mixing Python and C++ is much easier. <p> Compiling other languages to JVM? Yes, it's possible, just as a Turing machine can run any possible program. It's clear from the lack of, for example, nested scopes and pass by reference parameters that the JVM was designed solely to run Java. <p> I'm not saying that it is impossible to mix Java with other languages, just that the message coming through from Sun, intentional or otherwise, is that Java is the Answer to Life, the Universe, and Everything. <p> Which would be OK if, and it's a big if, the computing industry hadn't been through this before. COBOL was going to solve everyones problems. Then PL/I. Then Ada. Java? Been there, done that. <p> Even in the particular topic of distributed systems, I'm skeptical. The Internet, a "Traditional Distributed System" by Jim Waldo standards, hasn't exactly been a failure due to specifying protocols rather than languages or even APIs. <p> Lastly, another take on Java on an interesting web site: <p> http://www.jwz.org/doc/java.html <p>
I'm not saying that it is impossible to mix Java with other languages, just that the message coming through from Sun, intentional or otherwise, is that Java is the Answer to Life, the Universe, and Everything.
That's the message I get, too, an underlying attitude of "We know better." A good part of that is built in to the langauge; it's mostly OO, but not so much that a developer might do something too, um, too dangerous I suppose, such as subclass Integer, or add new methods to String.
It is, as A. Stepanov said [http://www.antiquark.com/escape/public_html/stepanovusa.html], designed for MOP: Money Oriented Programming. Which is fine. Sun is a profit-oriented business and will do what it needs to enhance business. That it produced an interesting and worthwile language as a by-product is great, but its design and development is focused on allowing certain types of developers to accomplish certain tasks.
That's it? That's the basis for liking Java? There have been many other more sucessful systems for mobile code. NextStep's PDO was brilliant and any Smalltalk implementation will have a more efficient code/data implementation with fewer typing issues than you run into with Java.
Those who refuse to learn history will repeat it with less style each time. I dislike Java because it is gratuitously complex and underpowered all at the same time. Am I a language snob? I program equally well in C, C++, Java, Objective C, and Smalltalk. Apart from C, these languages divide neatly into flexible/dynamic/elegant/simple and static/complex/fragile/work intensive. Where to draw the line is left as an exercise to the reader.
> NextStep's PDO was brilliant and any Smalltalk > implementation will have a more efficient code/data > implementation with fewer typing issues than you run > into with Java.
Que? I used PDO back in the day; it was a brilliant dynamic RPC system that avoided the problems of generating stubs a la CORBA and RMI by leveraging the Objective-C runtime.
However, it did *not* provide mobile code in the sense of JINI and some RMI: servers and clients could exchange interface information, but not implementation code. (In fact they couldn't, since OPENSTEP could theoreticaly run on Mach/Intel, Solaris, or NT/Intel.) Each side still had to implement the PDO protocol. Contrast to JINI, where a proxy could use RMI, IIOP, DCE-RPC, XML-RPC, or any daft thing to communicate back to its server. For that matter, contrast to J2EE where one can upload a binary to a server and be sure it's (a) the right instruction set and (b) can be dynamically loaded without any (more) risk of core-dumping the server because it was compiled with outdated header files or screws up memory usage.
Granted, the ability to download or upload new code at runtime is underused in most Java apps I've seen. (Also, the one aspect of JINI I didn't like was the presumption of a JVM on both sides, as opposed to an implementation-independent discovery protocol that can provide Java class files.) But PDO is certainly not a replacement, unless NeXT or Apple added something after I left for the Java world in 1997.
OK, I reread the comment after my morning caffeine, and realized most of that comment pertained to Smalltalk systems.
While I don't know the Smalltalk world, my impression was that each vendor had its own proprietary representation for objects and classes. Maybe vendors allowed runtimes to dynamically import and export code, but except for a textual representation it's hard to imagine a way for products from two different vendors to exchange code.
If the medium of exchange was text, it's in principle no different from exchanging Tcl text, and maybe a step back from exchanging Python bytecodes (as the Pyro system does). Which does prove the point that Java doesn't do anything unique, but it does have an interesting combination of abilities for a mainstream language.
I'm going to agree with the article author in most of his points. Sticking to the meat and potatoes of the argument, I'll agree that Java's ability to declare and use mobile code is a big plus. Java's network awareness and focus in general, though not perfect all the time, is one of it's best qualities, along with it's ability to run on multiple platforms with minimal effort. It's a general-purpose programming language with a high degree of flexibility and extensibility.
Like 'em or not, applets started the whole thing off. Think back some years ago and remember your amazement at the ability to run an application *inside* a browser without having to specifically go download, install, and manage it locally (keep file space for it, uninstall/upgrade the application regularly, etc.). It's still there, and getting better all the time.
Add on Java's networking capabilities and you have a smart program interface with remote servers. And now add the latest WebStart and JNLP, and you've got a great application distribution and management system.
Sure, Perl was great for web apps in the early days, and C was used a lot, too. But it wasn't easy for large applications. Servlets and JSP turned a *lot* of heads, and the ability to write large web applications became a reality for a much larger group of programmers. Web Services were an easy add-on, as was support for truly "mobile" code, in the phone sense with J2ME communicating with servers.
Java has always been network-friendly and relatively programmer-friendly. It's easy enough to develop for and doesn't require onerous loads of development tools to develop small, smart, easy-to-deploy applications. Sure, it's sacrified a measure of performance, but that was *by design*. People always seem to think that Java was positiioned as a replacement for all previous languages when it wasn't. It was designed with specific purposes in mind, and happened to do a wide of things well, which is why it caught on.
Sure, it's not as "pure" as smalltalk in it's OO and language features, but that was *by design*. I still remember the earlier days of small talk when Parcplace and others had runtime images of 50+ MB back at a time when network backbones were just starting to upgrade to 10baseT and we were eagerly anticipating hard drives of 1GB. I don't know what smalltalk is like today, but when Java appeared it was a blessing to have small and easily deployable applications. Oh, and it was free. Took a while for a reasonable smalltalk distribution to get there, basicly after the commercial vendors started giving up on it. And as Frank mentioned, vendor interoperability just wasn't there. Sun really was brave to make Java free, and while they've never been able to truly capitalize on Java, they could have.
One last point - Java does have warts. It could really use a few changes - remove all deprecated methods, make primitives into real object, and a wee bit of API cleanup to make things consistent. But warts and all it's still a really good programming language (and platform layer, if you want to call it that, too). C# has provided an alternative that has fixed a few of Java's flaws, but C# has it's own flaws as well.
Java should always be considered a tool in the toolbox. It happens to be more like a Leatherman than anything else, and you still need hammers, saws, drills, etc. for other tasks. Someday Java will be replaced by a much better language. It wouldn't bother me if Sun is the one that came up with it, as they've been a good steward for Java. I plan to keep Java in the front of my toolbox for forseeable future, and like any good geek, I'll keep looking for something better and I'll keep using the other tools when I need them.