2003-04-29 13:56:45

Followups on The .NET Abstraction Pile

Near the bottom of my article on The .NET Abstraction Pile, I mention that we've had some bad experiences with Java here at SourceGear.  Yesterday I was pleasantly surprised when Joel Spolsky linked my article (thanks Joel).  Today my mailbox is filled with email from Java fans telling me my remarks were unfair and incorrect.

My opinions about Java were certainly not the real point of my article.  I only mentioned our negative Java experiences as one example of how I have come to mistrust high-abstraction environments.  But now that this can of worms has been opened, I want to offer a few followup remarks:

First of all, if you're a Java fan, you probably should just not bother reading my stuff.  :-)  I'm pretty much all about .NET now.  I don't have the knowledge, the time or the desire to actually fight a .NET vs. Java war.

Yes, I know that .NET stands on the shoulders of Java.  In fact, when I first saw C# presented at a DevelopMentor seminar, I was amazed at the similarities.  It seems obvious that the C# team's kickoff meeting was very short:  Hi everyone.  Thanks for coming on such short notice.  Go clone Java.  Any questions?

Yes, I know that a comparison of Java and .NET is an "apples-to-oranges" issue.  After all, Java aims to be cross-platform and .NET (so far) does not.  I recognize this as a big issue.  I like .NET a lot, but even now I envy Java folks because SWT looks like it might actually be a viable technology for cross-platform UI development.

Everyone wants to know about the "projects which completely failed because Java was chosen".  Very briefly, here's the scoop:

• One of them was a consulting project my company was doing for Arthur Andersen.  This project happened ages ago, around 1997.  The UI was done with Swing.  Memory usage issues were a nightmare.  The killer bug was a problem which caused the JRE to crash whenever we tried to print.  Sun was openly acknowledging the bug and refusing to provide a fix until JDK 1.1.7.  By the time 1.1.7 was available, the decision to kill the project had been made.  I probably should have done this project in VB.
  
  
• The other "failed" project was the Motorola MAP phone.  SourceGear was one of many subcontractors involved in this project.  We wrote two browsers for this phone.  The MAP environment was Java-based, apparently using a hybrid of technologies from Sun and from a third-party somewhere in England.  In the end, the entire phone project was cancelled, apparently because the performance and stability could not meet consumer grade standards.  I'm sure there were dozens of reasons why this project failed.  In my opinion, the choice of Java was one of those reasons.

So if you're a Java fan, you are breathing a sigh of relief right now.

"Oh good.  Eric is clueless and his perspective on Java is years out of date.  Nothing to worry about here."

No problem.  :-)  Like I said, slamming Java was not the point of my article.  I've had some positive experience with C# and some negative experience with Java, but my experience is a pretty small dataset.  Java today is probably a lot better than it was in 1997.  Great.

Bottom line:  The fact that my Java criticisms fall apart under close inspection does not invalidate the real points of my article:

• Good technology decision making requires you to know what's going on underneath the abstractions.
  
  
• Really tall piles of abstractions should be treated with suspicion.  So far my experience with .NET has been a pleasant surprise, but a really conservative ISV project manager today might still avoid C# and Java in favor of C++.

By the way, not all of our Java experience has been negative.  The SourceOffSite server is written in Java, and that product has been very successful for us.

Oh yeah, one more thing:  Thanks to those who pointed out my mistake on UDP vs. IP.  The article has been corrected.  :-)