Why am I doing this?

I want to bring some more competition and originality into Java programming. People should learn to expect more of web games than just another Mine Sweeper, Breakout or Tetris. Similarly, amateur programmers should feel compelled to perform better.

That trend may already be well under way, but I perceive there is a definite risk of it heading in the wrong direction. We are facing the development of an "elite" class of Java applets, with impeccable quality, but which will only perform well on computers with lightning-fast Internet connections, tons of memory, 600-MHz processors, displays the size of a barn door ... oh yeah, and let's not forget JIT compilers.

It's difficult to make programmers with state-of-the-art hardware hold back when the awkward nature of Java has crippled their machines to such a great extent already, but it's necessary if Java applets are truly meant to be platform-independent. Please note the distinction here: despite the efforts of its creators, the programming language Java is not and has never been close to platform-independent in itself. At best, some Java applications or applets might be.

This brings us to another goal of mine, which is a bit more complex and requires some background.

"Write once..."

Most people familiar with Java have heard the motto "write once, run anywhere", conveying the intention that a finished piece of Java code will behave identically regardless of the user's hardware or operating system. Likewise, they have heard the resignated "write once, debug everywhere" coming from programmers who know from experience that a Java applet working perfectly in Windows Explorer may be a complete disaster in Macintosh Netscape, and vice versa.

Unlike regular computer programs, Java applets do not run on a fixed, factory-made piece of hardware. They run on a simulator -- a "virtual machine" that each Java-capable browser implements its own version of. So far no one has ever built a fully accurate Java simulator and, from the looks of it, no one ever will.

With the exception of Macintosh Netscape 4.x, which from a Java programmer's point of view is a fetid pile of swine excrement, it is normally possible to compensate for any given browser's flaws. But a hundred different browsers, each with its own bugs that in themselves would cripple the language just a tiny bit? Counting all versions of merely Netscape and Explorer, that's the situation today. People don't always bother to upgrade, so every browser version released during at least the past three years is still in use by someone, somewhere.

In a misdirected attempt at dealing with this, many commercial sites recommend their visitors to use only the latest version of the leading browsers for the leading operating system. "Netscape 4.0 or later for Windows required." Aside from the fact that this makes it pointless to use Java in the first place -- they might as well have built a much more efficient Windows application instead -- there is still no guarantee that the applet will work. The reason is that later browsers will have new faults that the Java programmers can't know about in advance. On more than one occasion I've written a game that worked properly in the newest versions of Windows Netscape (and older versions as well) when it was finished, but started crashing inexplicably after a year or two. It turned out that the newly released Windows Netscape 4.5 had a bug in its implementation of the MemoryImageSource class that the earlier versions did not.

Since you can't very well expect people to downgrade their web browsers in order to use your applets, what you are left with is "write once, debug forever."

An example

Anyone trying to build a Java applet will have to fight years of accumulated incompetence of a hundred corporate programmers. It usually doesn't matter how simple the applet is. Anything beyond "Hello World!" will create a problem on some platform. Let's say you want that text to be 10-point Helvetica in bold style. (As some of you may know, the Helvetica font is actually "deprecated", so to ensure compatibility you'd first have to do a getFontList() call and scan for "Helvetica" in the string array. If it's not there, you go with "SansSerif" instead.) Well, tough luck! Both Windows and UNIX Netscape 4.5 contain a bug that makes it impossible to render Helvetica in bold when it is smaller than 11 points.

Perhaps you have written an applet in the past that made use of that very font. Then you have two options. Either you don't care that your text now looks a bit skinny in UNIX and Windows (this will be unacceptable if you need bold-style Helvetica to appear distinct from the plain one), or you re-write the applet to work with a slightly larger font instead (which may require hours of modifications to your layout). Frustrating, isn't it? And whenever a new version -- of any browser -- is released, there's a chance you will have to "fix" your applet again to get around some other problem.

To hell in a handbasket

The WWW made Java popular, but it seems that its only future is as a "regular" programming language, whose programs can only run in the same environment as where they were built. Platform-independence was an intriguing idea that proved unfeasible due to the human factor. It would have required browsers that kept getting better, or at least did not contain any new bugs in updated versions.

Or is there still a chance to save the language? The only one who can do that is Sun, by putting greater pressure on software developers that license Java. But they are never going to do that, since it would counteract their policy of spreading Java to as many platforms as possible, as quickly as possible. And so they just look the other way and leave it to the end programmers to clean up the mess.

I want people to become aware of this hopeless situation. Eventually that insight might work its way back to Sun and make them reconsider their priorities. Even if not, I will be satisfied with having made clear that when Java for the WWW draws its final breath, it wasn't my fault.