Java Success Stories
gark writes "The Java Lobby has a
weblog on Java success stories. Many of the successful applications are servlet based, and several use Apache JServ. Perhaps WORA [write once, run anywhere] really has been achieved, at least for server apps."
A major part of the game in introducing any new
technology to the MIS-managers is producing a
panoply of success stories in the "trade press".
If you read back issues of "Information Week"
"Datamation" etc. you will find endless gushing
stories of successful implementations of
(pick the fad of the last 10 years).
What is *never* covered are the projects that
got abandoned, canceled, or crashed and burned
in some other way... these are politely buried
and not talked about... the programmers fired,
and the memory traces remain only in the minds
of the survivors - again never talked about, and
never included in survey tabulations...
The only way to find about project failures is to
talk to seasoned survivors over a beer, or
to read anti-patterns books or occasionally
the halloween issue of Datamation - and even
then they never give names and places...
The company I work for recently programmed an SMS (cellular phone text-messages) server complete with a fancy web based user interface and a vCal integration that allows you to synchronize your cellular phone calendar with your desktop calendar automatically with SMS's as the carrier protocol. One team had worked on this for months and months using C/C++ and Perl. The deadline came closer and the app was still packed with bugs. So a hail-Mary manouver was performed only days before the deployment date and the whole thing was re-engineered in Java with parts of the vCal integration being Visual Basic. On the deployment date, we had a ready package which was actually FAR better than the C/C++ & Perl version. It had more features, was more easily integratable with other systems, featured a pluggable SMSC (short message system center) driver architecture, had a fancy self-repairing system which did self-monitoring of the whole thing. We had a home-brew RMI based distributed debugging service that allowed us to receive stack-traces and exceptions that occured at run time, from several servers at once and view them on the web. We had about a million other equally cool things, all put together in less than one week by a handful of programmers.
A few weeks later, there are still no major bugs reported and everything seems to be running perfectly smoothly.
What does this prove? Absolute nothing. However, it does raise some questions about how it's idiotic to just do everything with C/C++ because it's traditionally "the right thing to do". By using "traditional" programming languages, you will often be forced to spend so much time thinking about language issues, memory allocation & leaks, complex threading issues etc. that the application logic will suffer and become a secondary priority.
Pick the right tool for the right job. If you develop a web browser, you would probably be insane if you did it in Java (I would love to be proved wrong) because it would be so much slower. If you develop a complex server side application in C/C++ or Perl, you're nuts because there's NO WAY you will achieve the same quality in the amount of time you can achieve it in Java.
If you diss Java because of some stupid web applets programmed by some 13 year olds who know nothing about programming, it's just very sad because Java can do so much more. Unfortunately we see lots of "write once debug everywhere" statements by people who have little or no first hand experience with Java. The experience I have with Java tells me that while the Win32 platform still has the best virtual machines, Linux is gaining FAST, mostly thanks to IBM. Linux users: don't just use Kaffe because you've heard it's the right thing. Try running Java on a Win32 platform so you see what it CAN be like. I'm quite sure you will be amazed of the speed.
There are not many platform inconsistencies left, and if you know what you're doing, you can easily move a Java app from one platform to another without having to change any code or recompile anything. I've done this several times, even for very large and complex applications.
If you read the Java 2 Enterprise Edition Application Programming Model specification which now has an even more complex name which escapes me at the moment, you will see how SUN has worked hard in the EJB specification to define a great component architecture that is scalable, clusterable and avoids many common causes for platform specific bugs. Please read it!