|
Menu
Learning Java
Articles
Author Profiles
Lessons
FAQ's
Books
Newsletter
Tutorials
Talk Java!
Using Java
Applets
JavaBeans
Servlets
Resources
Discuss Java
Looking for Java resources? Check out the Java
Coffee Break directory!
|
Findings of fact in Microsoft trial reveal attempts
to undermine Java
On Friday, November 5, 1999, the initial findings of
fact in United States of America v Microsoft Corporation were
released. Judge Thomas Penfield Jackson issued the findings of fact on
Friday afternoon. The document describes the anti-competitive activities
of Microsoft, ranging from bundling the Internet Explorer browser to
topple Netscape, to pricing behavior. Of particular interest to Java
developers are the sections of the finding pertaining to Microsoft's
attempts to thwart the success of Java, by developing incompatible
versions and inducing developers to use these versions in preference to
those offered by Sun Microsystems.
Judge Penfield starts by giving an overview of Java, and
the relationship between Sun and Netscape.
B. Sun's Implementation of the Java Technologies
73. The term "Java" refers to four interlocking elements.
First, there is a Java programming language with which developers can
write applications. Second, there is a set of programs written in Java
that expose APIs on which developers writing in Java can rely. These
programs are called the "Java class libraries." The third
element is the Java compiler, which translates the code written by the
developer into Java "bytecode." Finally, there are programs
called "Java virtual machines," or "JVMs," which
translate Java bytecode into instructions comprehensible to the
underlying operating system. If the Java class libraries and a JVM are
present on a PC system, the system is said to carry a "Java
runtime environment."
74. The inventors of Java at Sun Microsystems intended the
technology to enable applications written in the Java language to run
on a variety of platforms with minimal porting. A program written in
Java and relying only on APIs exposed by the Java class libraries will
run on any PC system containing a JVM that has itself been ported to
the resident operating system. Therefore, Java developers need to port
their applications only to the extent that those applications rely
directly on the APIs exposed by a particular operating system. The
more an application written in Java relies on APIs exposed by the Java
class libraries, the less work its developer will need to do to port
the application to different operating systems. The easier it is for
developers to port their applications to different operating systems,
the more applications will be written for operating systems other than
Windows. To date, the Java class libraries do not expose enough APIs
to support the development of full-featured applications that will run
well on multiple operating systems without the need for porting;
however, they do allow relatively simple, network-centric applications
to be written cross-platform. It is Sun's ultimate ambition to expand
the class libraries to such an extent that many full-featured,
end-user-oriented applications will be written cross-platform. The
closer Sun gets to this goal of "write once, run anywhere,"
the more the applications barrier to entry will erode.
75. Sun announced in May 1995 that it had developed the Java
programming language. Mid-level executives at Microsoft began to
express concern about Sun's Java vision in the fall of that year, and
by late spring of 1996, senior Microsoft executives were deeply
worried about the potential of Sun's Java technologies to diminish the
applications barrier to entry.
76. Sun's strategy could only succeed if a Java runtime environment
that complied with Sun's standards found its way onto PC systems
running Windows. Sun could not count on Microsoft to ship with Windows
an implementation of the Java runtime environment that threatened the
applications barrier to entry. Fortunately for Sun, Netscape agreed in
May 1995 to include a copy of Sun's Java runtime environment with
every copy of Navigator, and Navigator quickly became the principal
vehicle by which Sun placed copies of its Java runtime environment on
the PC systems of Windows users.
77. The combined efforts of Netscape and Sun threatened to hasten
the demise of the applications barrier to entry, opening the way for
non-Microsoft operating systems to emerge as acceptable substitutes
for Windows. By stimulating the development of network-centric Java
applications accessible to users through browser products, the
collaboration of Netscape and Sun also heralded the day when vendors
of information appliances and network computers could present users
with viable alternatives to PCs themselves. Nevertheless, these
middleware technologies have a long way to go before they might
imperil the applications barrier to entry. Windows 98 exposes nearly
ten thousand APIs, whereas the combined APIs of Navigator and the Java
class libraries, together representing the greatest hope for
proponents of middleware, total less than a thousand. Decision-makers
at Microsoft are apprehensive of potential as well as present threats,
though, and in 1995 the implications of the symbiosis between
Navigator and Sun's Java implementation were not lost on executives at
Microsoft, who viewed Netscape's cooperation with Sun as a further
reason to dread the increasing use of Navigator.
The first accusation leveled at Microsoft was that it developed an
implementation of Java that undermined the portability of the language.
The vision of Java is to Write-Once, Run Anywhere (WORA) - but this
dream was dashed by the JVM that Microsoft released. Particularly
interesting sections are highlighted.
Ironically this highlighting currently only works in Internet Explorer!
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.
The court's findings of fact reveal that Microsoft actively attempted
to induce developers to use the incompatible Microsoft
"features", in preference to those offered by Sun.
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.
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.
D. The Effect of Microsoft's Efforts to Prevent Java from
Diminishing the Applications Barrier to Entry
407. Had Microsoft not been committed to protecting and enhancing
the applications barrier to entry, it might still have developed a
high-performance JVM and enabled Java developers to call upon Windows
APIs. Absent this commitment, though, Microsoft would not have taken
efforts to maximize the difficulty of porting Java applications
written to its implementation and to drastically limit the ability of
developers to write Java applications that would run in both
Microsoft's version of the Windows runtime environment and versions
complying with Sun's standards. Nor would Microsoft have endeavored to
limit Navigator's usage share, to induce ISVs to neither use nor
distribute non-Microsoft Java technologies, and to impede the
expansion of the Java class libraries, had it not been determined to
discourage developers from writing applications that would be easy to
port between Windows and other platforms. Microsoft's
dedication to the goal of protecting the applications barrier to entry
is highlighted by the fact that its efforts to create incompatibility
between its JVM and others resulted in fewer applications being able
to run on Windows than otherwise would have. Microsoft felt it
was worth obstructing the development of Windows-compatible
applications where those applications would have been easy to port to
other platforms. It is not
clear whether, absent Microsoft's interference, Sun's Java efforts
would by now have facilitated porting between Windows and other
platforms enough to weaken the applications barrier to entry. What is
clear, however, is that Microsoft has succeeded in greatly impeding
Java's progress to that end with a series of actions whose sole
purpose and effect were to do precisely that.
A copy of the entire findings of fact is available from
Microsoft, at http://www.microsoft.com/presspass/trial/
|
