Java Is Dead Discussion

Overflow from JavaIsDead -- TomStambaugh

I think the participants in this discussion would do well to explore the history of Smalltalk, especially as regards performance, its relationship to graphics, its image model, and the questions of portability and adaptability. We learned many lessons the hard way, and made huge, stupid, and glaring mistakes along the way. It pains me to see another generation of smart and hard-working developers making the same mistakes -- those who do not know history are destined to repeat it. -- TomStambaugh

I'm not sure I understand. How am I ignoring my experience in SmallTalk and other VM-based OO languages? -- RobertDiFalco

My view is that it was the effort of the Smalltalk and Lisp community to fulfill these claims -- most especially the claims of binary portability -- that killed the commercial success of those communities. Smalltalk, especially ParcPlace Smalltalk, had a well-deserved reputation for being both a dog and a pig, especially on PCs and Macs. This was because ParcPlace insisted on preserving the "purity" of the image -- the graphics were emulated, to preserve the look and feel, and the VM was compromised to preserve the binary portability. Now, twenty years later, I see the Java community being torn by the same issues. Sun insists on protecting the "purity" of AWT, and resists efforts to wire it directly to the Windows Toolbox. The VM is compromized so that it can run on a huge variety of platforms (and I'll resist the temptation to start the argument about the Java type system, and whether it has helped or harmed overall performance). I believe that the Java community has given up huge advances in tools, architecture, and flexibility (in comparison with Smalltalk ... not C++) because of its resistance to incorporating the learnings of the Smalltalk and Lisp communities that came before it. This, in my view, is an avoidable tragedy. -- TomStambaugh

Tom, I think you are looking for simple, consistent answers that are not there. While there are many similarities with SmallTalk, there are many differences too. One is that what you propose hurt SmallTalk, binary independence, is the very thing that made Java so initially popular. How would you propose supporting distributed web-based applications with something that doesn't have a VM? You talk like Java and SmallTalk users are two different generations. You should be aware that many SmallTalk users are Java users! And most of us are aware of these issues. Are you actually proposing that giving up the VM would make Java more successful? Come one, things are more complicated than that. There are many issues at play. If we believe your point of view, Java would have never even made a blip on the map. The fact is that many interpreted languages fail and many compiled languages fail. What conclusion do you draw from that? See, maybe I see a different lesson. That a language like Java shouldn't attempt to be a general purpose language. There are some things it is good at, and other applications it is not good for. For me, attempting to blur this line would be making the mistakes of the past. It sounds like you want Java to be C++, but they are different languages with different uses. I don't think things are as black and white as you would like to believe. There are definitely a lot of things wrong about Java like its type-system or resistence to formalized standardization. These problems are, in fact, very much un-like the problems of LISP or SmallTalk. -- RobertDiFalco

TomStambaugh comments: Robert, I've never argued against the Java VM -- my point is that having a VirtualMachine does NOT imply binary portability, nor is binary portability a particularly important objective. In my view, every VM needs to have some sort of foreign function/primitive capability -- JNI in Java. Each platform has platform-specific libraries that are required by the Java application -- the most obvious example being the UI classes. Mostly, I think the Java experience has confirmed the correctness of most of the Smalltalk design decisions -- especially the big ones (like strong typing). Now we just have to be patient while the Java language and community catches up to where Smalltalk was in, say, 1990.

Tom, could you please give us the bulleted summary, for us ignoramuses (ignorami)?

Performance A: Micro-performance doesn't matter, macro performance is everything.
Performance B: Optimize bottlenecks first. You have to measure in order to identify a bottleneck. A primitive (JNI) and blindingly fast implementation of a method that is never called is a waste of time.
Graphics: People hate waiting for something to happen on their screen. Make something happen, fast. The animated window frame that a 128K Mac put on it's screen when a window was opened was an example -- easy to do, not much overhead, and created the illusion of blinding speed.
Portability A: Nobody cares. If there enough seats to make a given platform commercially interesting, there is enough revenue from those seats to pay for a specialization that exploits the specifics of that platform. Microsoft owns the desktop. Live with it.
Portability B: True (binary) portability is impossible. Virtual machines are always slower than physical machines.
- These two bullets are not true. While physical machines are slower than VM's that doesn't mean no one cares about binary portability. Much of Java's success is just because of its binary portability -- especially for Client/Server based systems and applets. I mean, come on!! Java would have never become as popular as it is if it didn't have binary independence. Here, we use that feature all the time. While there is some tweaking to be done, it is till much easier to port than C++. This is as bad as being culturally unaware. There are many billion dollor companies out there whose non-microsoft business is as big as their microsoft-based business. Read the trades. FWIW, I used to think this too, so don't feel too bad.
- Remember UCSD Pascal -- excellent p-code, supremely portable binary format, now completely irrelevant. [Wha? What does that mean? Are you saying that if I bring up a machine compiled language that is no longer relevant it will mean that nobody wants natively compiled languages? Come on, lets put on our thinking caps here.] No, just that binary portability is no guarantee of success, no what the application. There was the claim that the p-code version would survive the onset of native pascal compilers...
- Discussion moved to BinaryPortabilityWithTweakingDiscussion
- I'm well aware of the non-microsoft companies, though I'm not sure there are "many". But I don't think those companies care one iota about binary portability. -- TomStambaugh.

: You don't think there are many companies who are ISV's for Solaris, AIX, IRIX, and so on? You must have a different definition of many than me. There are even languages that don't run on Windows. You really have to get out more. Trust me, companies working on distributed, clustered/parallel system do care about binary portability. Until you start working on one, you shouldn't assume. But, maybe you have some card up your sleeve on how to create and deploy MultiAgentSystems without a virtual machine.
: TomStambaugh comments: I'm not sure there are "many billion dollar companies out there whose non-microsoft business is as big as their microsoft-based business". In fact, I'm not sure there many billion dollar companies out there, period. I've been working on "distributed, clustered/parallel systems" for nearly twenty years. Yes, of course virtual machines are required -- but "binary portability" is not. As you said earlier, tweaking is always required. In 1991, using Digitalk SmalltalkV and EnvyDeveloper, I was able to rigorously specify (using prerequisites, config maps, and prerequisite expressions) precisely what code should get loaded on what configuration of hardware, software, and environment. Java has provided NONE of the facilities that make that possible. So don't lecture me about "getting out more". I suggest that you try harder to learn from those who've come before you.

At least, without Java's virtual machine, yes. It's called Python, or Lisp, or some custom widget being developed in a lab. People have been building virtual machines for many years now, and the JVM isn't the first to use them.

Well, I think the original argument was that somehow we weren't learning from the mistakes of SmallTalk because Java had a VM, used P-code, and was going for some amount of binary portability. If you look at the bullet it says that no one cares about binary portability. So, Python or LISP, in this case, is the same as using Java. It's a language with a VM.

: It's probably somewhat ill-advised to assume what those on Wiki are working on. Java isn't the final answer for distributed/clustered/parallel computing. Java is the final answer for those who aren't willing to consider the alternatives, or those who are happy with the 'write once-test everywhere tweak-and-repeat' cycle, or those who think performance issues can always be fixed by adding more machines.
: Ahhh... now you are starting to get my point. (a) Java is an alternative not a final answer for every situation and (b) there are many different types of systems out there, not just the kind you are working on. Just because you don't work on a system where Java turns out to be the best solution shouldn't lead you to believe that you have any general view of the development landscape. There are a lot of smart people out there who are using Java because, for better or worse, it was wieghed as the best alternative for what they needed. And believe me, a lot of them are as observant and as smart if not smarter than both of us. You make it seem as if anyone would be dumb for being silly enough to settle for Java. It is this view that is limitted and narrow. All I've been trying to argue that Java isn't the final answer for every situation. It is only one of many answers. It is appropriate for some situations and not for others. It is unwise to assume you have the final word on a languages usefulness based only on their narrow experience with it. How hard can this be to grok?

Actually, we *do* use Java where it's appropriate, and it's an excellent solution for those problems. Really. Trust us on this. Just because you're working on a system where Java turns out to be the best solution shouldn't lead you to believe that you have any general view of the development landscape. There are a lot of smart people out there who are not using Java because, for better or worse, it wasn't weight as the best alternative for what they needed. And believe me, a lot of them are as observant and as smart as you, some probably even smarter than both of us. You make it seem as if anyone would be dumb for being silly enough to not settle for Java. It is this view that is limited and narrow. All I've been trying to argue is that Java isn't the final answer for every situation. It is only one of many answers. It is appropriate for some situations and not for others. It is unwise to assume that you have the final word on a language's usefulness based only on their narrow experience with it. How hard can this be to grok? Assuming that someone has limited experience with Java when they choose not to use it for everything is probably not a safe choice.

Where in this exchange have I ever said anything about Java being good for every use. You can't simply turn my own arguments on me and claim this was your point of view from the beginning. You started off with a general comment that Java was bad and that one could do the same with CeePlusPlus easier. I responded that Java is a fine solution depending on the problem, for example MultiAgentSystems. Now, you are saying that Java is one of many answers. If you agree that Java is a good solution for some situations and a horrible solution for others then we agree and there is not reason to continue going around in circles like this.

OK, now things make sense -- I didn't claim that Java was "bad", just that binary portability wasn't all that I would have hoped. I think you're confusing me with another one of the anonymous authors. Easy enough...

TomStambaugh comments: I don't have a horse in this particular race. My observation was, and is, that the Java community could learn more from the experience of the Smalltalk community that came before it. Period.

Adaptability A: People choose a platform and expect everything on it to be consistent. Digitalk & IBM ST killed ParcPlace because they accepted and exploited the LookAndFeel? of their platform.
Adaptability B: Smalltalk's view of the "perfect UI" was not universally held. Digitalk offered Toolbox compatibility, but they were a non-starter in the Business community. By the time IBM Smalltalk gave the market a Smalltalk that conformed to the Windows LookAndFeel?, it was too late.

I hope this helps...these are just my opinions, feel free to comment, change, add, or remove--TomStambaugh

Thanks Tom.

As far as I can tell, the killer problem for Java is very simple: It is massively overengineered. This has led to:

Bloated, esoteric class libraries...Calendar, or the Stream hierarchy for example.
Slow runtimes - window system portability and all that costs a lot - more than we are willing to pay in performance.
Esoteric language features: inner classes to work around static typing problems, overuse of exception handling to overcome the lack of blocks
APIs which grow ever larger with each release, but don't become fundamentally more functional: Talking to a relational database is an exercise in futility without a third party library.
An enormous memory footprint. It's maddening that you need 64MB of ram to run a small web server that is effectively moving pages of text and numbers at comparatively low speed and at low bandwidth.

Sorry if this sounds harsh, but that's my experience with the technology.

Smalltalk is an entirely different story: It was killed by poor marketing, poor response to customer demand and overal crappy business practices.

--AnthonyLander

I'll agree that there is a large difference between SmallTalk and Java. I think it is naive not to recognize that. However, I almost think Java was under engineered rather than over. I think of continued engineering almost as widdling down a piece of wood. There seems to be little widdling down in Java. It is inching ever closer to an AmorphousBlobOfHumanInsensitivity. There is little consistency between the runtime libaries, the type-system is seriously schizophrenic. Naming conventions and idioms for classes, methods, and packages are different from package to package. Too often, class designers go for C++ like designs such as using ExternalIterators in the Collection classes which would have performed much better as InternalIterators with closures. In fact, performance tests show a dramatic increase in efficiency after replacing the Java Collection Classes with a more object-oriented collection hierarchy. I think the problem can be summed up with consistency and coordination. I think the teams do not coordinate their efforts so multiple solutions are provided. Consider J2EE and Jini. Why is there no shared design or implementation? Consider JSSE, JAAS, java.security, and now RMI Security. All of which chose different solutions for those areas where their problem-spaces overlap. They really need to work towards coordinating their efforts and reject every addition that decreases consistency. This is very different from SmallTalk which took consistency and common metaphors to an extreme. -- RobertDiFalco

I suppose if they had reengineered (read: fixed) some of the early design problems, for example, the type system or the requirement to decalare exceptions on every method (without providing an "all" keyword), they might not have had to overengineer the libraries to work around them. --AnthonyLander

TomStambaugh comments: My view is that Java is well-intentioned but naive. Smalltalk, in 1980, already reflected the combined experience of TWELVE years of work by some of the most talented developers our industry has produced. Early (pre-1980) Smalltalk environments showed some of the bloat, unreliability, and inconsistency of today's Java. For example, the Java approach to class objects is precisely the model used in Smalltalk-78 -- every class is an instance of class "Class". There was a *reason* why the Smalltalk-80 double-rail metaclass hierarchy was introduced! Had the Java community taken the time to understand those reasons, we might be much further along today.

RobertDiFalco comments: Actually, Java reflection is much different from metaclasses in SmallTalk. They are not instances of true classes but instead an instance of a weird factory object that cannot be extended or whose instance members become class members to a non-metaclass. I assume they did this to deal with the performance problems associated with a real metaclass system. However, I would have preferred a real metaclass that has instance data added than the cheap static substitution provided by Java.

TomStambaugh comments: Well, I was trying to be gentle and tolerant with the Java community. You're absolutely correct, of course. They aren't classes *at all* (just try doing anything interesting with static methods). I think it's possible to build and wire in a Smalltalk-style metastructure, I just haven't tried it. I've heard assertions that EJB's are effectively that.

Java is an excellent language for some problem domains which has been pushed as the "perfect language" for all problems.

This has generated some annoyance from those who are tired of having to explain why Java isn't the perfect language for a given problem...

Amen! It's awfully frustrating the black & white point of view most people have -- Either its bad for everything or its good for everything!! Yeesh.

The deep irony here is the same person who wrote this is the same person you claim not to be able to have a discussion with above. :-) Oh well, I've enjoyed the discussion -- hope it's not upsetting you too much.

Actually, it's not that ironic since I knew it was the same person. I just thought I'd meet your annoyance with my frustration! ;)

Oi, this page was flame bait from the moment the link was created. Hmm. Maybe we should start a discussion over whether the whole discussion is irrelevant with the advent of native code Java compilers? Perhaps standardization vs. innovation? Maybe it's time for "CeeSharpIsDead?"?

Many people supported Java for reasons other than technical excellence. Some jumped on a bandwagon. They thought there was safety in the herd. These people can be fickle. Many of them switched away from C++ and if a C# bandwagon emerges, or gives the appearance of emerging, they may switch again.

Some followed Java for ideological reasons. One group saw Java as a possible escape from the dominance of Microsoft. They will continue to favour Java over C# until they are convinced Microsoft has become trustworthy. Another group tends to follow the Microsoft party line. These may adopt C# when they wouldn't other languages, because they think if you want to play on Microsoft's platform you should follow Microsoft's rules.

Either way, technical excellence will not be the deciding factor for many people. -- AnonymousDonor [See WorseIsBetter -- rad]

(I edited the above to make it less pithy, full of "some" and "many". I wouldn't have wanted the previous, extreme form to be the only viewpoint offered, but I had felt it balanced by the rest of the page. The watered-down version is less offensive but also almost vacuous. Anyway, you may want to update or delete your criticisms below. -- AnonymousDonor)

AD says technical excellence won't be the deciding factor, and RDF hears "Java users don't care about technical excellence". How does that work?

Actually, the quote from AD that is being countered is "Java supporters are, almost by definition, fickle. If they cared about technical excellence the would be using [other languages]." While it's split up into three sections it is all a single post from AD. I haven't studied logic for a long time, but this clearly indicates that if you have decided to use Java instead of language x, y, or z then you don't care about technical excellence. Seems pretty straight forward to me.

It's obviously a StrawMan argument. But that's an honest mistake (I hope).

Ignoring for the moment the issue of what a particular technology delivers versus promises to deliver, versus is capable of delivering, the telling difference for me between DotNet and Java is the multiple language support.

However, there is nothing that I know that prevents OtherLanguagesCompiledAsJavaByteCodes?, in fact I'm pretty sure that this capability is already availiable for Ada.

So its my hope that the DotNet 'threat' will encourage Sun and others to put together some sort of uniform support for compiling other languages to JVM bytecodes. Has anyone know of any other efforts in this area? -- MikeKrajnak

JPython does this. See http://www.jpython.org/docs/whatis.html for more...

Go to http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html for a whole raft of languages that emit Java byte codes. I've used Kawa (a Scheme implemented for the VM) to good effect.

There's also Jasmin perl-to-java bytecodes http://www.ebb.org/perljvm/

Other language support was possible with the JVM, but not very easy, especially if you wanted reasonable efficiency. For me this is the single biggest improvement Microsoft have (allegedly) made. Eg I believe ISE had tried an Eiffel-to-JVM project but gave up. Ditto for Smalltalk. Both these languages have been seduced by CommonLanguageRuntime. This is where Sun has really screwed up.

GNU-Eiffel can compile to Java byte code. The main reason that ISE didn't follow it up is because the separate class files in Java limit how much global optimisation can be done and its one of ISE's key tactics for getting decent dperformance out of Eiffel (Its also one reason we TowerJ ended up so fast).

The Java versus C# issue is much less interesting than the JVM versus CLR one. -- DaveHarris

Q: Is the CLR based on Simonyi's work in the IntentionalProgramming group?

Well, if you've done CeePlusPlus and Java, played on MSFT platforms and know COM, played with JVMs, I guess that it is not that difficult to move to CeeSharp, basically they added what's was left out of Java. For the DotNet, it seems okay to work with that. Why wouldn't Java be able to support DotNet interoperability ? It's just a matter of another (perhaps bloated) API. When we look at XML, Java is pretty usable, so why not with SOAP and all which are not very transcendental ideas after all. If anyone has done some CORBA, it is a piece of cake. The main problem here is that LifesTooShort to learn them all. As always, the real goal is to tackle the problem at hand, not to prove that something is better than something else. And it all depends on the PoliticalContext.

So, Java is not dead as the concepts contained in the language have spread some interesting designs into the head of the common developer. Just for that, it was worth existing.

--PhilippeBack

CategoryDiscussion