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
- 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
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. :-)