Over the years I've cultivated a genuine and deep-seated dislike for Java. The latest round came over the last few days when I wrote a new testing applet for DrDave. I figured it would be a pretty simple affair, as it's a cut down version of stuff I'd done for him before. It just presents you with a pile of questions. After you've answered 'em all, it calls a server-side CGI (also done in Java) that stores all of the responses as a comma-separated row in a text file. Apart from the 250 hard-coded questions, there's about 300 lines of code in the entire thing, client and server.

Well, I got the applet done, we tested in-house a bit, sent some clients to it, and that's where the fun began. People started emailing that the applet was either bombing out or it was popping up boxes on the user's screen trying to download the Java plug-in. It made absolutely no sense because it was based on some earlier testing stuff we'd done that was actually MORE complex. There was nothing in the HTML or the code that I hadn't done a dozen times before.

Or so I thought.

DrDave's other test applets did neat stuff like track if you went back and changed an answer, so I originally used a dynamically-growing vector of responses. Since this new applet didn't care if you went back and changed an answer, I removed all the answer-tracking and made the vector a fixed size. First thing the new applet did was to add 250 empty strings to the Answers vector. Then as people answered questions I'd just replace the empty string at that index with the answer. And at the end I could simply look for all the empty strings to warn the user if he forgot to answer the question. Simple huh?

My loop to add all those empty strings was this. . .

for (int i=0; i
Answers.add(new String(''));

Unbeknownst to me, the add() function of the vector object is a Java 1.2 or later kind of thing, so anyone with an older browser or an older Java VM will either get a crashed applet or a complaint that they need to update their VM. To fix the problem, I did the following. . .

for (int i=0; i
Answers.addElement(new String(''));

Yep that's right. There's an addElement() function that is COMPLETELY IDENTICAL to the add() function in every way EXCEPT that the addElement() function works for all VM's and the add() function will bomb out any VM earlier than Java 1.2.

And that, my faithful readers, is why I've cultivated a genuine and deep-seated dislike for Java. To call the Java class library a huge mess would be an insult to huge messes. It's such a hodgepodge of redundant functions and deprecated objects that doing anything with intent to distribute to the public requires you to have a ridiculous amount of knowledge of class library arcana. Trying to deploy an applet to a wide-ranging audience requires you to either support the oldest possible version of Java or to hope that everybody running your applet is willing to update their VM. . .and I can guarantee that most people don't know how to do that.

While finding and fixing the problem I was reminded of a browser-games-roundtable I went to at GDC last year. One of the guys from PopCap software (one of the most popular browser game companies out there) said that their internal policy is to write everything to work with Java 1.0 and only to resort to Java 1.1 functions only if they've got a damn good reason to do so, as it's the only way to ensure that their stuff can run on everybody's machine.

That means that they've gotta follow a standard that's almost eight years old just to ensure that their games won't bomb on many browsers.

Java was an interesting experiment, but it fumbled badly. After eight years, there's still not a reasonable deployment mechanism that can recover gracefully if there's a version number conflict. I don't know if the class library was just badly designed from the start or if it later fell into the hands of academic object-heads who decided that they could do better, but this constant adding of redundant functions and deprecating old stuff has made the while system worse than unruly.