A. Creating a Java Implementation for Windows that Undermined Portability and Was Incompatible with Other Implementations

387. Although Sun intended Java technologies eventually to allow developers to write applications that would run on multiple operating systems without any porting, the Java class libraries have never exposed enough APIs to support full-featured applications. Java developers have thus always needed to rely on platform-specific APIs in order to write applications with advanced functionality. Recognizing this, Sun sponsored a process for the creation of a software method that would allow developers writing in Java to rely directly upon APIs exposed by a particular operating system in a way that would nevertheless allow them to port their applications with relative ease to JVMs running on different operating systems.

388. On March 12, 1996, Sun signed an agreement granting Microsoft the right to distribute and make certain modifications to Sun's Java technologies. Microsoft used this license to create its own Java development tools and its own Windows-compatible Java runtime environment. Because the motivation behind the Sun-sponsored effort ran counter to Microsoft's interest in preserving the difficulty of porting, Microsoft independently developed methods for enabling "calls" to "native" Windows code that made porting more difficult than the method that Sun was striving to make standard. Microsoft implemented these different methods in its developer tools and in its JVM. Microsoft also discouraged its business allies from aiding Sun's effort. For example, Gates told Intel's CEO in June 1996 that he did not want the Intel Architecture Labs cooperating with Sun to develop methods for calling upon multimedia interfaces in Windows.

389. Since they were custom-built for enabling native calls to Windows, and because they were developed by the firm with the most intimate knowledge of Windows, the native methods that Microsoft produced were slightly easier for developers to use than the method that derived from the Sun-sponsored effort, and Java applications using Microsoft's methods tended to run faster than ones calling upon Windows APIs with Sun's method. If a developer relied on Microsoft's methods rather than Sun's, however, his Java application would be much more difficult to port from the Windows-compatible JVM to JVMs designed to run on different operating systems.

390. Microsoft easily could have implemented Sun's native method along with its own in its developer tools and its JVM, thereby allowing Java developers to choose between speed and portability; however, it elected instead to implement only the Microsoft methods. The result was that if a Java developer used the Sun method for making native calls, his application would not run on Microsoft's version of the Windows JVM, and if he used Microsoft's native methods, his application would not run on any JVM other than Microsoft's version. Far from being the unintended consequence of an attempt to help Java developers more easily develop high-performing applications, incompatibility was the intended result of Microsoft's efforts. In fact, Microsoft would subsequently threaten to use the same tactic against Apple's QuickTime. Microsoft continued to refuse to implement Sun's native method until November 1998, when a court ordered it to do so. It then took Microsoft only a few weeks to implement Sun's native method in its developer tools and JVM.

391. Although the Java class libraries have yet to provide enough functionality to support full-featured applications, they have gradually expanded toward that goal. In 1997, Sun added a class library called Remote Method Invocation, or "RMI," which allowed Java applications written to call upon it to communicate with each other in certain useful ways. Microsoft was not willing to stand by and allow Java developers to rely on new Java class libraries unimpeded. The more that Java developers were able to satisfy their need for functionality by calling upon the Java class libraries, the more portable their applications would become. Microsoft had developed a set of Windows-specific interfaces to provide functionality analogous to the functionality RMI offered; it wanted Java developers to rely on this Windows-specific technology rather than Sun's cross-platform interface. Microsoft thus refused to include RMI as a standard component of the Java runtime environment for Windows that it shipped with Internet Explorer 4.0.

392. The license agreement it had signed with Sun the previous year obligated Microsoft to offer RMI, at a minimum, on its developer Web site. Microsoft did so, but with respect to the RMI beta release, it buried the link in an obscure location and neglected to include an entry for it in the site's index. Referring to RMI and any Java developers who might access Microsoft's site looking for it, a Microsoft employee wrote to his approving manager, "They'll have to stumble across it to know it's there. . . . I'd say it's pretty buried."

393. It is unclear whether Microsoft ultimately placed RMI in a more prominent place on its developer Web site. Even if it did, the fact that RMI was not shipped with Microsoft's Java runtime environment for Windows meant that Java developers could not rely on its being installed on consumers' PC systems. If developers wanted their Java applications to call upon communications interfaces guaranteed to be present on Windows users' systems, they had no choice but to rely on the Microsoft-specific interfaces instead of RMI. Microsoft undertook the effort to remove RMI from the rest of the Java class libraries, instead of simply leaving it in place and allowing developers to choose between it and Windows-specific interfaces, for the sole purpose of making it more difficult for Java developers to write easily portable applications.

394. In a further effort intended to increase the incompatibility between Java applications written for its Windows JVM and other Windows JVMs, and to increase the difficulty of porting Java applications from the Windows environment to other platforms, Microsoft designed its Java developer tools to encourage developers to write their Java applications using certain "keywords" and "compiler directives" that could only be executed properly by Microsoft's version of the Java runtime environment for Windows. Microsoft encouraged developers to use these extensions by shipping its developer tools with the extensions enabled by default and by failing to warn developers that their use would result in applications that might not run properly with any runtime environment other than Microsoft's and that would be difficult, and perhaps impossible, to port to JVMs running on other platforms. This action comported with the suggestion that Microsoft's Thomas Reardon made to his colleagues in November 1996: "[W]e should just quietly grow j++ [Microsoft's developer tools] share and assume that people will take more advantage of our classes without ever realizing they are building win32-only java apps." Microsoft refused to alter its developer tools until November 1998, when a court ordered it to disable its keywords and compiler directives by default and to warn developers that using Microsoft's Java extensions would likely cause incompatibilities with non-Microsoft runtime environments.

Microsoft Findings Home
Findings of Judge Thomas Penfield Jackson, Nov. 5, 1999