Java on the Client: Fossil or Future Fuel?
The biggest fallout for business from the Sun-Microsoft territorial wars is the difficulty of writing apps that work across various Java virtual machines.

The schism means that unless businesses exert absolute control over the software used by their partners and clients, they are likely to rely on HTML or early and widely deployed Java Development Kits (JDKs) for extranets and the Internet. Intranets may even feel repercussions if desktop uniformity is not maintained.

This affects scalability, functionality and bottom-line costs, because HTML processing is server-centric and lacks Java's flexibility to farm out processing.

Sun also views Microsoft's support for J/direct, rather than its own Java Native Interface, as harming portability--but even some of Sun's partners disagree about this. JNI amounts to a hole in the bottom of the Java platform to invoke underlying platform-specific functionality. J/direct ties an application to the Windows platform by making it easier to write applications in Java that make Win32 calls. But if you are writing an application that requires native calls, you are obviously not worried about portability, some Java adherents contend.

While the battles rage on, Java's enterprise momentum is moving away from the client--where it predominates--to the server.

Even without Microsoft, client portability headaches were inevitable. One of the most significant problems lies with Java's quick evolution and its instantiation in the form of multiple JDK point releases. While Sun promises backward and forward compatibility in its JDKs (with the exception of a few features, such as the interface in its initial JDK), most developers find they must limit functionality to early JDK 1.1 or 1.02 clients for applications.

Some third-party developers, after bleeding on the edge, began redeveloping client Java applications in HTML to get around the patchwork of JVM functionality disparities peppering Java's evolution.

More than anything--even performance--most enterprise managers say they want Sun to deliver on its promise to provide stable APIs in JDK 1.2, slated to ship next month. That's apparently a wish Sun is heeding: The vendor is delaying its HotSpot Java Virtual Machine (JVM) accelerator until the first quarter of 1999 in order to concentrate on producing an extremely stable JDK 1.2.

The second problem for Java on the client is that it was developed with 32-bit architectures in mind. Since the bulk of business desktops, roughly 40 percent to 60 percent worldwide, have yet to upgrade, they aren't great candidates for a JVM. This is especially true if you take into account the extra distributed processing tasks inherent in Microsoft's COM (Component Object Model) or the Object Management Group's CORBA (Common Object Request Broker Architecture).

Mike Hilton, chairman and CTO of Concur Technologies (formerly Portable Software), found that even though his company's travel-expense automation application was built using about 80 percent HTML/JavaScript and 20 percent Java, customers wanted "no Java whatsoever." In response, Concur this month will release a pure HTML version. Hilton believes it may take up to two years before Java on the client has sufficient presence for the type of widespread enterprise application Concur sells. This is unfortunate, he adds, because Java affords a much richer interface and better data entry. "You might make Windows 3.1 eke through somehow with Java," adds Aberdeen Group analyst Tim Sloane, "but anyone who used it would say it sucked."

There is an emerging alternative, however: JavaPC, a Java environment slated to ship by year's end, based on the JavaOS used for network computers. JavaPC can co-exist with DOS or Windows 3.1 on older Pentiums or 486 machines as long as slimmed-down applications are the rule (see "JavaPC: Sub-$100 Miracle Worker?," page 62).

It's ironic that businesses that have standardized on Windows95 desktops are probably the ones best suited to tap the administration, security and portability gains inherent in Sun's Java client--that is, the very desktops least likely to have the latest Sun JVM. That's because Java's base was spilled out of the browsers offered by Netscape and Microsoft. After lagging in its responses to new JDKs, Netscape decided to bail out of the difficult task of JDK provisioning for multiple platforms--or at least bail out of timely JDK provisioning--in favor of an API approach. This left the task of creating and distributing the newest JVMs to individual platform providers. It is extremely unlikely that Netscape will bundle these third-party JVMs with its browser.

If the task of JVM unification can't be mandated by requiring a particular browser version, a huge burden is passed onto business, which would seem to give Microsoft a significant JVM distribution advantage. But Sun's group manager for the Java platform, Gina Centoni, bristles at the notion that businesses might rely on the Microsoft JVM--like many other Windows capabilities--simply because it's bundled with the desktop. There are also software vendors who complain that even though Microsoft's JVM is optimized for Windows performance, it lacks the stability and reliability of Sun's JVMs.

Sun's solution to these client woes is the Java Plug-in. This free software checks whether the correct JVM is installed when a browser sees a Java applet. If not, the correct JVM then can be downloaded. This means if a Microsoft JVM is installed and a Sun JVM is required, the Sun JVM will be downloaded.

META Group analyst Craig Roth says he considers Plug-in a tactical solution, especially for companies with modem users who may balk at the time required to download a JVM application. Microsoft Internet Explorer users may be intimidated, too, when asked to accept an ActiveX download. Businesses must also modify Web pages so applets can identify client software--a process that can result in nagging obsolescence issues if, for example, Microsoft renamed its Internet Explorer. Finally, in large businesses, the rollout of any new application, including an ActiveX Control or Plug-in, is no trivial matter.

Microsoft Visual J++ product manager Bill Dunlap argues that Sun has yet to prove it can offer a JVM with reasonable performance and is simply moving in too many directions at once.

Sun partners agree that the task of Java development plus a reorganization at Sun seem to be consuming resources. They'd like Sun to distribute tasks to partners--but that entails surrendering some of the control it exercises over Java. "A lot of people were looking at Java to be the Holy Grail," Roth says. "The problem is setting expectations. Java comes closest to 'write once, run anywhere.'"