Sun-Microsoft: Missed opportunities

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

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

Java was met with much fanfare throughout the computerindustry when it was released in 1996, including atMicrosoft. News stories from the period detailedenthusiasm for Java among Microsoft's own developers. Microsoft R&D in particular did a lot of interestingthings with Java. This research led to a Java VMwhich was the fastest of any that existed at the time. J++, Microsoft's development tool, was widely praisedas one of the best Java IDE's available. WithMicrosoft's investment and support, Java's place asthe software architecture of the future seemedassured.

Things started to go wrong, at least from Sun'sstandpoint, when Microsoft tried to add extra featuresto it's VM, or remove features it didn't like. Oneexample was the Microsoft VM's failure to support JNI,a native code interface which enables Javaapplications to call native operating systemfunctions. They developed their own technology,called J/Direct, that made it easier to make suchcalls (no need for the JNI “harness” code). Microsoftdecided not to include RMI with its class library, atechnology released with JDK 1.1 in February of 1997as Java’s standard architecture for remotely invokingobjects. Microsoft also made additions to the Javalanguage, creating "delegates" as a streamlined meansto handle event notifications (and a feature now foundin C#).

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

Microsoft had different plans with respect to WORAcapability. As a software maker that creates productsfor 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 itimpossible to differentiate their products in themarket. To that end, they added features to their VMthat made it easier for applications to call nativecode (and thus, the Windows APIs) through J/Direct,created their own windowing class library which wasmore 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. Theresult was that Microsoft jettisoned Java from futureplans for Windows.

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

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

What if Sun had said: "fine, you can add featuresspecific 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 alreadywhere it needed to be. As Larry Seltzer indicated ina recentarticle, tests indicated that the Microsoft VM wasthe most compatible Java implementation in existence. Pure Java applications wouldn't be making nativecalls, anyway, and Sun certainly could have gottenMicrosoft to include RMI (and even JNI) in exchangefor giving them the freedom to extend their Java VM.

As for releasing Microsoft VM extensions back to theJava community, there is evidence that Microsoft wouldhave been amenable if Sun had asked. The following isfrom an article found in theJuly, 1999 edition of Javaworld:

Of course, one might point out that Java is Sun'sproprietary technology, and thus Sun gets to say whatgoes into it. Though that is true, it makes littlebusiness sense if Sun's goal was to expand the numberof software choices available on non-Microsoftplatforms. Sun would have done far more to achieveits goal by harnessingthe Microsoft momentum, rather than fighting it inthe courts.

As Neward indicated, even Windows-oriented developerswanted something cross-platform. Sun could haveleveraged that demand, providing something thatMicrosoft would not. They would have an easier jobof convincing those Windows developers to jump totrue, cross-platform Java if those developers werealready using Java in some form. Furthermore, if theycould 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 partlydescribed as a lack of belief in developer ability to discriminate between cross-platform Java, and Javatied to a particular platform. As the JavaWorldarticle indicated, Microsoft-centric developers wishedthat certain features specific to Microsoft's VMexisted in other VMs. They DID NOT say they did notwant those extra features, just that they wished theyexisted cross-platform.

This reveals a number of things. First, developerscan tell the difference between cross-platform Javaand the sort that is tied to a particular platform. Second, there was a demand for a cross-platformproduct among Windows developers, a demand that Suncould have filled through its own libraries or bycloning Microsoft libraries, like Ximian is doing withthe .NET Framework. Third, it shows that Microsofthad 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 recognizeMicrosoft's importance in the software market. Asmaker of the most popular software products in theworld, Microsoft's decision to support a technology intheir own products can make or break that technology. Furthermore, Microsoft wields considerable influenceamong Windows developers as maker of Windows, asauthor of some of the most popular software productsthat run on Windows, as premier vendor of developmenttools for Windows, and as a source of information forWindows developers (MSDN, Microsoft Press, etc.). Convincing Microsoft to use a technology makesattracting Windows developers to that technology mucheasier. Given that the majority of developers in theworld program for Windows, that's important.

Sun should have concentrated on getting Microsoft tosign on to an infrastructure that had the potential tobe cross-platform, even if Microsoft itself was notcommitted to perfect cross-platform support. Microsoft would have wielded its considerable leveragein the technology world to popularize the Javaplatform, along the way familiarizing Windowsdevelopers with Java technology. Understanding theconcepts of a VM environment is far more work thanlearning an API, and the job of attracting developersto other platforms would have been made that mucheasier.

Sun had an opportunity to influence technologydirections at Microsoft. They might have ended upwith substantial leverage, even if they had lesscontrol over the direction of Java. Instead, theyhave guaranteed that Microsoft will apply itsconsiderable resources to a technology Sun cannotcontrol. If I am right, and .NET does end up "conqueringthe world" as it grows into a cross-platformunification technology, Sun's lack of flexibilitymight be considered a strategic error on par withIBM's decision to sign a non-exclusive agreement witha certain unknown software company in Washingtonstate.

John Carroll is a software engineer who lives in Switzerland. He specializes in the design and development of distributed systems using Java and .Net. He is also the founder of Turtleneck Software.