B. Inducing Developers to Use the Microsoft Implementation of Java Rather than Sun-Compliant Implementations

395. If all Microsoft had done to combat the growth of easily portable Java applications had been to increase the incompatibility between its Java implementation and ones complying with Sun's standards, the effect might have been limited. For if Sun could have assured developers that a Windows-compatible Java runtime environment that complied with Sun's standards would be installed on as many Windows PCs as Microsoft's version, and that it would run Java applications as well as Microsoft's, developers might have considered the cost in portability associated with relying on Microsoft-specific technologies and instead written their Java applications using Sun's developer tools. When Netscape announced in May 1995 that it would include with every copy of Navigator a copy of a Windows JVM that complied with Sun's standards, it appeared that Sun's Java implementation would achieve the necessary ubiquity on Windows.

396. Determined to induce developers to write Java applications that relied on its version of the runtime environment for Windows rather than on Sun-compliant ones, Microsoft made a large investment of engineering resources to develop a high-performance Windows JVM. This made Microsoft's version of the runtime environment attractive on its technical merits. To hinder Sun and Netscape from improving the quality of the Windows JVM shipped with Navigator, Microsoft pressured Intel, which was developing a high-performance Windows-compatible JVM, to not share its work with either Sun or Netscape, much less allow Netscape to bundle the Intel JVM with Navigator. Gates was himself involved in this effort. During the August 2, 1995 meeting at which he urged Intel to halt IAL's development of platform-level software, Gates also announced that Intel's cooperation with Sun and Netscape to develop a Java runtime environment for systems running on Intel's microprocessors was one of the issues threatening to undermine cooperation between Intel and Microsoft. By the spring of 1996, Intel had developed a JVM designed to run well on Intel-based systems while complying with Sun's cross-platform standards. Microsoft executives approached Intel in April of that year and urged that Intel not take any steps toward allowing Netscape to ship this JVM with Navigator.

397. By bundling its version of the Windows JVM with every copy of Internet Explorer and expending some of its surplus monopoly power to maximize the usage of Internet Explorer at Navigator's expense, Microsoft endowed its Java runtime environment with the unique attribute of guaranteed, enduring ubiquity across the enormous Windows installed base. As one internal Microsoft presentation from January 1997 put it, the company's response to cross-platform Java entailed "[i]ncreased IE share -- integrat[ion] with Windows." Partly as a result of the damage that Microsoft's efforts against Navigator inflicted on Netscape's business, Netscape decided in 1998 that it could no longer afford to do the engineering work necessary to continue bundling up-to-date JVMs with Navigator. Consequently, it announced that, starting with version 5.0, Navigator would cease to be a distribution vehicle for JVMs compliant with Sun's standards.

398. The guaranteed presence of Microsoft's runtime environment on every Windows PC and the decreasing likelihood that the primary host of the Sun-compliant runtime environment (Navigator) would be present, induced many Java developers to write their applications using Microsoft's developer tools, for doing so guaranteed that those applications would run in the Java environment most likely to be installed on a Windows user's PC. Owing to Microsoft's deliberate design decisions, more developers using Microsoft's Java developer tools meant that more Java applications would rely on the Windows-specific technologies in Microsoft's runtime environment and thus would not be portable.

399. Microsoft was not content to rely solely on its anti-Navigator efforts to ensure that its Java runtime environment would be the only one guaranteed to be present on Windows PC systems. After all, Netscape was not the only ISV capable of placing copies of a runtime environment on users' systems. Many developers of network-centric applications were just as capable of bundling compatible runtime environments with their applications as they were of bundling browsing software. If the right runtime environment already came bundled with the right browsing software, all the more convenient for the ISV. If not (as would increasingly be the case after Netscape stopped bundling a runtime environment with Navigator), though, the ISV could still separately obtain the desired runtime environment and bundle it with every copy of its product.

400. Recognizing ISVs as a channel through which Java runtime environments that complied with Sun's standards could find their way onto Windows PC systems, Microsoft induced ISVs to distribute Microsoft's version instead of a Sun-compliant one. First, Microsoft made its JVM available to ISVs separately from Internet Explorer so that those uninterested in bundling browsing software could nevertheless bundle Microsoft's JVM. Microsoft's David Cole revealed the motivation for this step in a message he wrote to Jim Allchin in July 1997: "[W]e've agreed that we must allow ISVs to redistribute the Java VM standalone, without IE. ISVs that do this are bound into Windows because that's the only place the VM works, and it keeps them away from Sun's APIs."

401. Microsoft took the further step of offering valuable things to ISVs that agreed to use Microsoft's Java implementation. Specifically, in the First Wave agreements that it signed with dozens of ISVs in 1997 and 1998, Microsoft conditioned early Windows 98 and Windows NT betas, other technical information, and the right to use certain Microsoft seals of approval on the agreement of those ISVs to use Microsoft's version of the Windows JVM as the "default." Microsoft and the ISVs all read this requirement to obligate the ISVs to ensure that their Java applications were compatible with Microsoft's version of the Windows JVM. The only effective way to ensure compatibility with Microsoft's JVM was to use Microsoft's Java developer tools, which in turn meant using Microsoft's methods for making native calls and (unless the developers were especially wary and sophisticated) Microsoft's other Java extensions. Thus, a very large percentage of the Java applications that the First Wave ISVs wrote would run only on Microsoft's version of the Windows JVM. With that in mind, the First Wave ISVs would not have any reason to distribute with their Java applications any JVM other than Microsoft's. So, in exchange for costly technical support and other blandishments, Microsoft induced dozens of important ISVs to make their Java applications reliant on Windows-specific technologies and to refrain from distributing to Windows users JVMs that complied with Sun's standards. The record contains no evidence that the relevant provision in the First Wave agreements had any purpose other than to maximize the difficulty of porting Java applications between Windows and other platforms. Microsoft remained free to hold the First Wave ISVs to this provision until a court enjoined its enforcement in November 1998.

402. In addition to the First Wave agreements, Microsoft entered an agreement with at least one ISV that explicitly required it to redistribute Microsoft's JVM to the exclusion of any other and to rely upon Microsoft's native methods to the exclusion of any other methods. Such agreements were also prohibited by the November 1998 injunction.

403. Microsoft anticipated that the Java language would become a popular medium in the multimedia arena. It thus wanted to ensure that the Java software created to deliver multimedia content would not rely on Java implementations that fostered portability. RealNetworks developed the most popular software for the creation and play-back of streaming multimedia content. Therefore, Microsoft sought to ensure that, to the extent Java developers relied on RealNetworks' technologies, they would not be relying on a Java implementation that complied with Sun's standards. So, in the July 18, 1997 agreement that it entered with RealNetworks, Microsoft conditioned its agreement to distribute RealNetworks' media player with Internet Explorer on RealNetworks' agreement to exert its best efforts to ensure that its player primarily use Windows-specific technology, rather than any analogous interfaces that Sun or Netscape might develop, to display multimedia content. Absent this obligation, there would have been no technical reason why RealNetworks could not have designed its media player to support both Microsoft's technologies and ones developed by Sun or Netscape. Although RealNetworks subsequently announced that it planned to continue developing its own fundamental streaming software, the July 18 agreement limited the extent to which that software would include Java technologies that complied with Sun's standards.

C. Thwarting the Expansion of the Java Class Libraries

404. As discussed above, Microsoft's effort to lock developers into its Windows- specific Java implementation included actions designed to discourage developers from taking advantage of Java class libraries such as RMI. Microsoft went further than that, however. In pursuit of its goal of minimizing the portability of Java applications, Microsoft took steps to thwart the very creation of cross-platform Java interfaces. The incorporation of greater functionality into the Java class libraries would have increased the portability of the applications that relied on them, while simultaneously encouraging developers to use Sun-compliant implementations of Java. In one instance of this effort to stunt the growth of the Java class libraries, Microsoft used threats to withhold Windows operating-system support from Intel's microprocessors and offers to include Intel technology in Windows in order to induce Intel to stop aiding Sun in the development of Java classes that would support innovative multimedia functionality.

405. In November 1995, Microsoft's Paul Maritz told a senior Intel executive that Intel's optimization of its multimedia software for Sun's Java standards was as inimical to Microsoft as Microsoft's support for non-Intel microprocessors would be to Intel. It was not until 1997, though, that Microsoft prevailed upon Intel to not support Sun's development of Java classes that would have allowed developers to include certain multimedia features in their Java applications without sacrificing portability.

406. In February 1997, one of Intel's competitors, called AMD, solicited support from Microsoft for its "3DX" technology, which provided sophisticated multimedia support for games. Microsoft's Allchin asked Gates whether Microsoft should support 3DX, despite the fact that Intel would oppose it. Gates responded: "If Intel has a real problem with us supporting this then they will have to stop supporting Java Multimedia the way they are. I would gladly give up supporting this if they would back off from their work on JAVA which is terrible for Intel." Near the end of March, Allchin sent another message to Gates and Maritz. In it he wrote, "I am positive that we must do a direct attack on Sun (and probably Oracle). . . . Between ourselves and our partners, we can certainly hurt their (certainly Sun's) revenue base. . . . We need to get Intel to help us. Today, they are not." Two months later, Eric Engstrom, a Microsoft executive with responsibility for multimedia development, wrote to his superiors that one of Microsoft's goals was getting "Intel to stop helping Sun create Java Multimedia APIs, especially ones that run well (ie native implementations) on Windows." Engstrom proposed achieving this goal by offering Intel the following deal: Microsoft would incorporate into the Windows API set any multimedia interfaces that Intel agreed to not help Sun incorporate into the Java class libraries. Engstrom's efforts apparently bore fruit, for he testified at trial that Intel's IAL subsequently stopped helping Sun to develop class libraries that offered cutting-edge multimedia support.

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