Sun-Microsoft: Missed opportunities

COMMENTARY--Microsoft's rejection of Sun Microsystems' Java is nearly complete. Save for the occasional nod towards Java's popularity in enterprise development, Java does not enter into any of the development plans at Microsoft.

This is the outcome of a three-and-a-half year legal battle over Microsoft's implementation of Java technology. Sun would have us believe that the successful suit saved the world from Microsoft's corruption of Java's "Write Once, Run Anywhere" (WORA) promise. In truth, all Sun has accomplished is to create a void for a VM-style technology on Windows, creating a market opportunity for the ultimate "polluted" Java (.NET). It would have been better for Sun to have allowed Microsoft to chart its own course with Java and relied on developers to make their own decisions than to chase off the investment and marketing muscle Microsoft could have put into Java.

Java was met with much fanfare throughout the computer industry when it was released in 1996, including at Microsoft. News stories from the period detailed enthusiasm for Java among Microsoft's own developers. Microsoft R&D in particular did a lot of interesting things with Java. This research led to a Java VM which was the fastest of any that existed at the time. J++, Microsoft's development tool, was widely praised as one of the best Java IDE's available. With Microsoft's investment and support, Java's place as the software architecture of the future seemed assured.

Things started to go wrong, at least from Sun's standpoint, when Microsoft tried to add extra features to it's VM, or remove features it didn't like. One example was the Microsoft VM's failure to support JNI, a native code interface which enables Java applications to call native operating system functions. They developed their own technology, called J/Direct, that made it easier to make such calls (no need for the JNI “harness” code). Microsoft decided not to include RMI with its class library, a technology released with JDK 1.1 in February of 1997 as Java’s standard architecture for remotely invoking objects. Microsoft also made additions to the Java language, creating "delegates" as a streamlined means to handle event notifications (and a feature now found in C#).

The essence of the conflict
Sun believed that Java's importance relied on the ability to write an application once and have it run on any "Virtual Machine" (VM) irrespective of the underlying OS. This "Write Once, Run Anywhere," or WORA, capability was intended to enable any platform to hook into a software market organized around Java, providing more applications for less popular platforms and eroding the application advantage held by Windows.

Microsoft had different plans with respect to WORA capability. As a software maker that creates products for a growing web of computing devices, it would be advantageous to write code once that could be used from any device. In addition, the security of downloaded code cannot be guaranteed in a networked world. This makes the security capabilities of a self-describing "bytecode" format like Java very compelling. Java is also an improvement on native code development, boosting productivity and making it easier to write bug-free, secure code. In short, Java would add a lot to the software development process, something of obvious interest to the largest software company in the world.

However, Microsoft was NOT interested in a making it impossible to differentiate their products in the market. To that end, they added features to their VM that made it easier for applications to call native code (and thus, the Windows APIs) through J/Direct, created their own windowing class library which was more expressive of the full WIN32 API (called Windows Foundation Classes, or WFC, and built on J/Direct), and made sure that all their developer tools supported these extra features. Though this made it easier to write Windows applications, it ran up against Sun's vision of a Java which was exactly the same on any platform.

Sun filed suit, a suit they won in the end. The result was that Microsoft jettisoned Java from future plans for Windows.

Conventional wisdom would say that this outcome was inevitable. But was it?

A different approach
Should Sun's primary goal have been to limit deviation to ensure perfect cross-platform support, or should it have been to ensure the largest software company in the world signed on to a technology capable of cross-platform support, even if said company wasn't committed to that aspect of it?

What if Sun had said: "fine, you can add features specific to your VM, so long as you at least support a reasonable core VM feature set and library, and additions to the VM core are released back to the Java community for possible inclusion by other implementers?" In other words, you must support the core so that developers have a consistent cross-platform baseline, but you can add whatever you want. It would have been a middle ground. Microsoft might have to support some of the features it had dropped from its VM, but would be free to add extras specific to its VM, even extras that extended the bytecode.

From a compatibility standpoint, Microsoft was already where it needed to be. As Larry Seltzer indicated in a recent article, tests indicated that the Microsoft VM was the most compatible Java implementation in existence. Pure Java applications wouldn't be making native calls, anyway, and Sun certainly could have gotten Microsoft to include RMI (and even JNI) in exchange for giving them the freedom to extend their Java VM.

As for releasing Microsoft VM extensions back to the Java community, there is evidence that Microsoft would have been amenable if Sun had asked. The following is from an article found in the July, 1999 edition of Javaworld:

Of course, one might point out that Java is Sun's proprietary technology, and thus Sun gets to say what goes into it. Though that is true, it makes little business sense if Sun's goal was to expand the number of software choices available on non-Microsoft platforms. Sun would have done far more to achieve its goal by harnessing the Microsoft momentum, rather than fighting it in the courts.

As Neward indicated, even Windows-oriented developers wanted something cross-platform. Sun could have leveraged that demand, providing something that Microsoft would not. They would have an easier job of convincing those Windows developers to jump to true, cross-platform Java if those developers were already using Java in some form. Furthermore, if they could copy additions made to Microsoft's VM, Windows' developers wouldn't have to sacrifice the things they like about the Microsoft VM in order to program for other platforms.

How prescient Mr. Albahari turned out to be.

Conclusion
Sun's error was multi-faceted. It can be partly described as a lack of belief in developer ability to discriminate between cross-platform Java, and Java tied to a particular platform. As the JavaWorld article indicated, Microsoft-centric developers wished that certain features specific to Microsoft's VM existed in other VMs. They DID NOT say they did not want those extra features, just that they wished they existed cross-platform.

This reveals a number of things. First, developers can tell the difference between cross-platform Java and the sort that is tied to a particular platform. Second, there was a demand for a cross-platform product among Windows developers, a demand that Sun could have filled through its own libraries or by cloning Microsoft libraries, like Ximian is doing with the .NET Framework. Third, it shows that Microsoft had some ideas related to Java that developers found interesting. Microsoft proved that they were willing to make their VM additions available to the wider Java community. That was free R&D work that Sun could have leveraged to boost the Java platform.

Sun's error also involved a failure to recognize Microsoft's importance in the software market. As maker of the most popular software products in the world, Microsoft's decision to support a technology in their own products can make or break that technology. Furthermore, Microsoft wields considerable influence among Windows developers as maker of Windows, as author of some of the most popular software products that run on Windows, as premier vendor of development tools for Windows, and as a source of information for Windows developers (MSDN, Microsoft Press, etc.). Convincing Microsoft to use a technology makes attracting Windows developers to that technology much easier. Given that the majority of developers in the world program for Windows, that's important.

Sun should have concentrated on getting Microsoft to sign on to an infrastructure that had the potential to be cross-platform, even if Microsoft itself was not committed to perfect cross-platform support. Microsoft would have wielded its considerable leverage in the technology world to popularize the Java platform, along the way familiarizing Windows developers with Java technology. Understanding the concepts of a VM environment is far more work than learning an API, and the job of attracting developers to other platforms would have been made that much easier.

Sun had an opportunity to influence technology directions at Microsoft. They might have ended up with substantial leverage, even if they had less control over the direction of Java. Instead, they have guaranteed that Microsoft will apply its considerable resources to a technology Sun cannot control. If I am right, and .NET does end up "conquering the world" as it grows into a cross-platform unification technology, Sun's lack of flexibility might be considered a strategic error on par with IBM's decision to sign a non-exclusive agreement with a certain unknown software company in Washington state.