he biggest fallout for business from the Sun-Microsoft territorial wars is the difficulty of writing applications that work across various Java virtual machines.
The schism means that unless businesses have absolute control over the software used by partners and clients, they are likely to rely on HTML or early and widely deployed Java Development Kits for Internet development. 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 Sun's own Java Native Interface, as harming portability--though some of Sun's partners disagree. But even without Microsoft, client portability headaches were inevitable. One of the most significant problems lies with Java's quick evolution and its representation in the form of multiple JDK point releases. Though Sun promises backward and forward compatibility in its JDKs (with the exception of a few features), most developers find they must limit functionality to early JDK 1.1 or 1.02 clients for applications.
Some third-party developers began redeveloping client Java applications in HTML to get around the patchwork of Java VM functionality disparities.
More than anything--even performance--most enterprise managers say they want Sun to provide stable APIs in JDK 1.2, slated to ship this month. That's apparently a wish Sun is heeding: The vendor is delaying its HotSpot Java Virtual Machine accelerator until the first quarter of 1999 to concentrate on producing a stable JDK 1.2.
The second problem for Java on the client is that it was developed with 32-bit architectures in mind. Since about half of business desktops have yet to be upgraded, they aren't great candidates for a Java VM. Sun's solution for these older machines