Intranet Design Magazine: Big Problems with Java

Feature
Black Hole Sun
Java is going supernova thanks to its creator's
gravitational pull

By Gordon Benett, Managing Editor

Apparently, no one ever explained to the executive management at Sun Microsystems that true love means letting go. CEO Scott McNealy and his colleagues pride themselves on using Sun Tze's Art of War as a playbook, and far it has gotten them: Sun is the #1 seller of computers not based on Intel microprocessors, while its Solaris operating system is the most widely installed flavor of Unix. Moreover, as one of the defining architects of Unix networking, the company created major chunks of the Internet, including the fundamental SMTP, FTP, and TCP/IP protocols.
Sun is also the author of Java, the programming language that for awhile promised to wipe away differences between platforms and usher in a Golden Age of object-oriented, thin-client distributed computing. But in contrast to the consensus building role Sun played in pioneering basic Internet technologies, it chose to hold the reins of Java tightly - as a direct result of which the language and its promises have stalled.
Bitter brew

Java is in big trouble for two reasons. The first of these, technical immaturity, boils down to the fact that after three years of enormous academic and commercial investment (to say nothing of its advertising budget), Java remains a slow, unstable and functionally limited platform. For example, the initial vision of Java as a means of delivering client-side applications on demand - that is, as applets - has reached its zenith in simple presentation aids such as zoomable maps or document viewers. (Even in this role Java is hobbled, however, since its security model doesn't allow screen content to be printed.)
Over the last year "serious" Java applications have moved from the client to the server, but here the platform's technical deficiencies are even more glaring. The server, after all, is where we demand software to scale, yet as a bytecode language - one that compiles code at run-time and executes in a software layer (or virtual machine) rather than directly on the server - Java is innately slower and more resource-intensive than compiled code.
To be fair, Java is not "deficient" in this regard since it is doing exactly what it was designed to do: run programs in an abstract layer to achieve platform independence. The problem is that platform-independence is at odds with scalability, which implies platform optimization. Java has enough virtues as a network-aware object-oriented language that it's time we dispensed with duplicitous rhetoric about "write once, run anywhere."
Escape velocity

In fact, this is just what Java's biggest boosters are doing. IBM, Hewlett-Packard, Novell, Inc. and Intel Corp. are each developing high-performance Java compilers to compete with Sun's JVM. Sun itself has been working on a multi-platform Java compiler called HotSpot, which the company claims will optimize bytecode on the fly for specific execution platforms.
Meanwhile, IBM released this month a Java Virtual Machine optimized for Microsoft Windows that provides "4 times the network scalability" and better performance than its closest competitor, according to John Neffenger, author of the industry-standard VolanoMark Java benchmark. The platform-specific JVM puts server-side performance ahead of portability and competes directly with Sun's yet-to-appear HotSpot compiler.
Nor is IBM the only Sun partner pursuing this strategy. HP is building a native Java compiler, due this summer, for its HP-UX operating system. As for Novell, it will soon ship a compiler called NetFire optimized to run Java under NetWare on Intel hardware.
The irony here is that Java was supposed to make heterogeneous computing easier - easier than, say, C++, for which developers required a native compiler for each platform. At this point the major players are all behaving much as Microsoft did when it introduced the Windows Foundation Classes (WFC) and J++ extensions. It is worth remarking that these same players were the ones that trashed Microsoft for trying to "kill Java" with its proprietary optimizations.
But Microsoft hasn't had to work hard to kill Java. Sun is doing it for them.
A house divided

In fact this isn't the first time an alliance between Sun, HP, IBM and others has deteriorated into factionalism, damaging the prospects for a promising technology. In the late 1980's, when DOS ruled the desktop, PCs were thought of as a sort of cross between an adding machine and a typewriter. For serious computing one required a Unix workstation, and for those, one looked to Sun, HP, IBM (or Digital, R.I.P.).
This was the status quo in computing for over a decade. Yet the most remarkable thing about the period is that it ended with Microsoft Windows dominating the desktop, workstation and server markets. How did a crude, buggy, single-user operating system running on 16-bit hardware come to challenge Unix, a mature 32-bit, multitasking, multi-user platform?
Factionalism and greed.
Against the crude unity of MS-DOS stood all those elegant Unix flavors - SunOS, HP-UX, IBM AIX, Digital Unix, SCO Unix, FreeBSD and so on. Good stuff, but customers voted for unity.
All the Unix vendors bear a share of the blame for failing to recognize that their market could only be defended through consensus. Instead of closing ranks, they chose to break a strong technology into myriad incompatible products, each with low volume and high costs. Instead of offering standards, they launched proprietary initiatives and branding campaigns that made IT crazy.
Most of the vendors practiced this destructive form of sibling rivalry, but Sun Microsystems played a special role in fomenting the infighting that, then as now, stunted a technology it had pioneered.
Take the example of X-Windows, a nonproprietary graphic user interface (GUI) standard for Unix developed by researchers at MIT. Recognizing its value, HP, IBM and Digital promptly banded together to support an X-Windows implementation called Motif. But Sun, with by far the largest market share, opted out, instead pushing its proprietary OpenLook windowing system. The result was confusion on the part of customers and paralysis on the part of developers. By the time Sun abandoned OpenLook in favor of Motif, stranding credulous early adopters, Microsoft Windows had begun its ascent.
Today, Sun's Java licensees are in thrall to a company that wants it all. Rather than opening Java in order to build a high-volume market and then competing on tools and services, Sun wants to regulate the market and treat its partners like value-added resellers. Naturally, companies like IBM, Hewlett-Packard and Novell aren't having any of it.
I'd invoke the cliché, "Those who can't remember the past are doomed to repeat it," but I'm not sure these players know what hit them the first time around.