It's funny; Sun Microsystems first unveiled its Java language in 1995. Since then, the computer-using public has been subject to an endless torrent of marketing and news coverage of the platform. And chances are, despite all the hype, five years later you're still trying to figure out just what Java is all about. I know I am — and I'm a Java developer.
By now, you've probably received at least a basic briefing on the wonders of Java. It's the "write once, run anywhere" language. A Java application developed on one computer can run unchanged on any other Java-enabled device, from desktop PCs, to network computers, to cell phones. We know this. Or do we?
Despite how often I've heard mention of such a device, I don't know of any Java-based consumer cell phone product now on the market. But even if we assume that a Java powered phone is feasible — and for that matter, beneficial — it seems doubtful that such a device could run the bulk of Java software now written for desktop machines. Getting the stuff to run on the desktop machines is difficult enough.
While it's true that the Java Virtual Machine (JVM) — the part of the Java system that actually executes Java code — has been ported to a variety of different platforms, not all JVMs are created equal. Stability varies as does speed. The JVM on one platform might not support the same version of the Java language as another. And, hamstrung by limitations in Java's core features, developers will often forsake the "run anywhere" Grail and instead choose to target their software for a specific platform — usually, Windows.
If you ask Sun Microsystems, they'll tell you that's exactly how Microsoft wants it. You've probably heard about that too: how Sun sued Microsoft for introducing features into its JVM that were Windows-specific, to encourage programmers to write code that was more Windows than Java. But the outcome of that case remains unresolved, and the issues aren't as cut-and-dried as they may seem.
Sun claims that Microsoft sees the Java platform as a threat, and so the Menace from Redmond is working to destroy Java by splintering the "standard." But if that's so, then why does Sun seem so eager to support Microsoft's OS? Developers looking to download Java components from Sun's website may choose from only two OS platforms: Sun's Solaris, and Windows.
Sun recently announced official support for Linux, but that option has yet to appear on most of the download menus. And all of this must be very confusing for the Macintosh-based Java developer. Which to pick? And if the message of Java is really platform independence, why must a choice be made to begin with?
Let's put that aside, though. Isn't it enough that Java runs in the most popular Web browsers? But then, we can't actually say that either. Macintosh and Unix versions of Internet Explorer no longer ship with any JVM, because of the legal climate between Sun and Microsoft.
And although Sun released Java 1.2 a year ago (and promptly changed its name to Java 2), to date both browsers only support the earlier 1.1.x version. Netscape claims it will support 1.2 with the next (much-delayed) version of its browser. AOL will support it soon, but not as the default installation. With Microsoft, who knows?
As a developer, this only contributes to the difficulty in approaching Java projects. Which version of the platform to write code for? With each new release, Java changes considerably. Java 1.1 contained literally twice as many code routines as the previous version. Other techniques became "deprecated" — Sun's word meaning it doesn't want us to use them anymore.
But as Java changes, how can we be sure these new routines will be supported in our customers' environments? Forget what Sun declares to be the "correct" way to write Java — which way is going to work?
For that matter, just what is it we're meant to be doing with the language? When Java first appeared, it was embraced for writing "applets," small snippets of code that run in the browser to do things like animation or flashy menus. But this market has largely been taken over by technologies like Macromedia's Flash and Shockwave for Director which, frankly, do the job better.
So now we're told Java is the language for enterprise-level client-server applications, including back office automation and e-commerce solutions. To this end, and adding to the confusion, Sun has broken its latest release of Java into two "editions."
The Java 2 Standard Edition (J2SE) is the old Java, good for writing applets and client-side applications. And now, the much-ballyhooed Java 2 Enterprise Edition (J2EE) contains special new programming interfaces targeted directly at developers of these large-scale, complex client-server applications.
I saw an ad on the Craigslist.org message board the other day, posted December 15, 1999, seeking Java programmers to do "ongoing development" on a Web application using J2EE. The ad was looking for experienced developers. That's always a wise choice, and seems perfectly reasonable, except for one minor point: Sun wouldn't finalize the specification for J2EE until December 17 — two days after the ad was posted.
Previously, the J2EE specification had been so volatile, technical writers could barely keep up with the documentation. For example, one core component of J2EE is a technology called Java Server Pages (JSP). And yet, O'Reilly Publishing's recent reference volume, Java Enterprise in a Nutshell, doesn't even cover JSP. The sole mention is to say the JSP standard was still being finalized as the book went to press.
In the meantime, the "experience" of Java Enterprise developers comes from tooling around with pre-release beta or "early access" releases from Sun. I've often heard corporate IT managers say they're skeptical of Linux-based solutions because Linux relies on so much beta software.
While that may be true, those same managers are often bullish on Java, which surely leaves them in the same boat. Anyone in need of mission-critical business solutions should clearly be skeptical of a specification that remains such a moving target.
For a while, Sun Microsystems flirted with the idea of turning Java over to an independent standards body for maintenance, as has been done with other non-proprietary languages like C++, Fortran, and Cobol. Now that it's abandoned that idea in favor of maintaining sole control of the Java standard itself, the onus is on Sun to do the job right, if the platform's future is to be assured.
What we have today is a cross-platform language that suffers from differences between platforms. We have a specification that's constantly changing and poorly documented, making training difficult and staying current costly. We have technologies that are aggressively marketed yet buggy and unfinished. And we have no clear direction for the platform, leaving us with a technology that's pitched to everyone yet really great for no one.
And still, five years later, the industry as a whole keeps waiting for Java. And even I'll admit: hype or no hype, the idea of Java is a good one. I'd like to see it work out, so I'll reserve judgement on the emperor's new clothes. But just, please — someone show me where the emperor is.
