|
IN THE UNITED STATES DISTRICT COURT
FOR THE DISTRICT OF COLUMBIA
UNITED STATES OF AMERICA,
Plaintiff,
v.
MICROSOFT CORPORATION,
Defendant.
STATE OF NEW YORK ex rel.
Attorney General DENNIS C. VACCO, et al.,
Plaintiffs,
v.
MICROSOFT CORPORATION,
Defendant.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Civil Action No. 98-1232 (TPJ)
FILED UNDER SEAL
(Seal removed pursuant to court's
October 14, 1998 Order
Civil Action No. 98-1233 (TPJ)
|
Statement of Dr. James A. Gosling
I. My Background
1. My name is James A. Gosling. I am employed by Sun Microsystems, Inc. ("Sun") as a
Vice President and Sun Fellow. I am the Chief Scientist of the Java Software Division,
where one of my main responsibilities is to review and guide the ongoing development of
the Java programming language and the Java Runtime Environment, which includes the
Java Virtual Machine and the Java class libraries, as explained below. I am making this
Page 2
witness statement at the request of the United States Department of Justice, in lieu of live
direct testimony in United States, et al. v. Microsoft Corp.1
2. I have been employed by Sun since 1984. At Sun, I have headed numerous projects
involving both operating systems and application software. For example, I was lead
designer and lead engineer in developing "NeWS," a UNIX-based user interface and
windowing system, and I was in charge of Sun's Graphics Architecture Committee, which
was responsible for graphics architecture oversight.
3. Before joining Sun, I was an employee of IBM Research Labs. I received a bachelors
degree in computer science in 1977 from the University of Calgary. In 1982 I received a
masters degree, and in 1983 a doctorate degree, in computer science from Carnegie-
Mellon University. While at Carnegie-Mellon, I developed one of the first multi-processor
enabled UNIX operating systems. I also developed numerous software programs,
including electronic mail systems for commercial customers.
4. Over the years I have become familiar with many programming languages. I have
developed software applications in C++ for Microsoft's Windows 3.X and Windows 95
platforms. I have received many industry honors and awards, including an Innovator of
Page 3
the Year award from Discover Magazine, and Software Development's "Programing
Excellence Award." I have been awarded over a dozen patents, and have published
several books and papers, as listed in the slightly out-of-date resume (it omits some new
patents that I have been awarded) attached as Exhibit 1.
5. I created the Java programming language and the first Java Virtual Machine in 1991 while
working on a research project at Sun. I also developed the first Java compiler and many
of the Java class libraries, all of which are explained further below. I also participated in
the development of the HotJava web browser, and I have written numerous software
programs using the Java language that I developed. Since 1992, I have worked
continuously with others at Sun to further develop the Java technology. I have authored
or coauthored every version of the Java Language Specification. I also represent Sun at
computer industry events, and I regularly monitor industry trends closely and speak with
software developers and computer users in order to help anticipate customer needs as we
develop the Java technology.
II. Overview of Software
A. Introduction
6. As is discussed below, the Java technology was designed with a principal objective of
eliminating a problem that software developers confront when working in traditional
Page 4
software environments: the need to create and distribute different versions of their
programs for different operating system and hardware platforms. To accomplish this goal,
the Java technology is specifically designed to give developers the ability to build software
applications that can run on multiple platforms.
B. Traditional Software Development
7. In order to understand the promise of the Java technology, one must first understand how
software is traditionally created for specific operating systems, such as Microsoft's
Windows operating system. On a PC or similar computer, there are traditionally two
layers of software: the operating system and the software programs (or "applications")
that run on the operating system. As I explain below, an operating system is designed to
function on a particular type of computer hardware, such as an Intel-based PC or an Apple
Macintosh with a PowerPC processor; an application is designed to run on a particular
operating system (and processor), such as Windows on Intel or the Mac OS on PowerPC.
Such operating systems and applications are thus said to be "platform-specific."
8. The operating system has two primary functions: (1) to interact with and control the
computer's processor and other hardware (monitors, keyboards, disk drives, etc.); and (2)
to interact with, and execute instructions from, software applications, generally through a
series of applications programming interfaces known as "APIs."
Page 5
9. Software applications are programs that one uses on a computer to accomplish particular
desired tasks, such as word processing, spreadsheet calculation, or browsing the World
Wide Web. They sit on top of the operating system and "plug in" through the APIs
mentioned above.
10. Applications software is first written with a programming language to create a set of
instructions called "sourcecode." When writing sourcecode for a traditional application,
the developer must be mindful of the underlying operating system, in order to successfully
invoke the operating system's APIs. These API's essentially provide the vocabulary of the
language understood by the operating system. If the sourcecode is not written to
accommodate the particular APIs of a given operating system, then the application will not
run on that operating system.
11. Sourcecode is "compiled," or translated into language directly comprehensible by the
computer system. This computer-readable language is generally called "binary code" or
"object code." Traditional compilers are designed specifically to create binary code for a
particular operating system and hardware platform. The binary code is then fully tested
and debugged on the specific operating system and hardware for which it was designed.
Page 6
C. The Problem with Platform-Specific Software
12. A major weakness of developing platform-specific software is that the resulting software
application is dependent on the specific operating system and hardware for which it was
designed. Such software cannot readily be used on other platforms. Thus, a program
designed for the Windows/Intel platform cannot be made to work on the
Macintosh/PowerPC or Solaris/SPARC platforms without significant additional work and
investment.
13. As seen on Exhibit 2, in order to create versions of a software application that work on
different platforms, a developer using a traditional platform-specific approach must write,
compile, test, and distribute each software application separately for each platform that the
developer wishes to support. Trying to reuse software code across platforms is very
difficult, time-consuming and expensive because one must go back and rewrite sections of
the sourcecode to take account of the differences in each platform. In order to write
software to run on different computer platforms, the developer must generally write to
different API sets for each platform, and must separately compile, test, and debug for each
platform. As programs grow more complex, rewriting versions of a program to run on
different platforms becomes increasingly difficult and expensive. This tedious process,
which is known as "porting" software to other platforms, dramatically increases the cost
of software programs, and consumes scarce time and resources that could otherwise be
devoted to developing innovative applications.
Page 7
14. These platform dependencies are an even bigger problem when different types of
computers are networked together, whether inside an enterprise or across the Internet.
One problem created by mixing different platforms on a network is the impossibility of
sharing platform-specific software applications across the network between different types
of computers. One cannot use traditional platform-specific software development to
create a single software application that can be accessed and used by Windows,
Macintosh, UNIX and whatever other platforms may be connected. For example, in a
corporation there might be Macintosh computers in the graphics department, Windows
PCs in accounting, HP-UX workstations in the engineering department, and IBM MVS
mainframes in inventory control. The corporation could not distribute a single software
application to run on all its different platforms, but would have to develop or otherwise
obtain, distribute, and support different versions of the program for each platform --
assuming it could even find a program that did what it needed and was available for all the
different platforms. This problem is particularly acute over extended corporate networks
(which link a firm with other firms, such as its customers and suppliers), and the public
Internet, because it is difficult to know, predict or control what types of computers and
other devices might be connected over these broad networks.
Page 8
D. Platform Dependencies Reinforce Windows' Dominance
15. The platform-specific nature of the traditional software development process tends to
reinforce the position of the dominant operating system. Developers using a platform-
specific approach tend to develop their software first -- and often only -- for the platform
offering the largest potential customer market. Creating and revising software
applications to run on other platforms can be prohibitively expensive for platforms without
a large enough market to defray costs. In the course of my work with software
developers, I have found that funding software development across multiple platforms is
often uneconomical, given the expensive tasks of re-coding, testing, debugging, updating,
and supporting multiple versions without a large enough potential customer market for
each version.
16. Even a well-established operating system like Sun's Solaris version of UNIX can face this
problem. I have had many conversations with developers who have developed Windows
applications, in which those developers lamented the fact that they cannot afford to modify
their applications to run on Solaris. Sometimes Sun has had to agree to fund third-party
developers' efforts to port particularly important applications to Solaris. Fortunately, Sun
has the financial wherewithal to do so on occasion. Many smaller or newer operating
system vendors do not.
Page 9
17. Computer platforms with smaller market shares thus tend to have fewer software
applications available for them. Certainly, new operating systems and platforms start out
at a significant disadvantage based on the amount of application software available. This
in turn makes these alternate platforms less attractive to users, since they have fewer
software applications available to do the tasks users wish to perform. Prospective
computer users want to buy computers (and operating systems) for which there are many
useful programs, particularly programs which the users have previously learned how to
work with. When these programs are available on a particular platform, customers are
more likely to purchase systems using that platform.
18. In the case of personal computers using the Intel x-86 hardware architecture, Microsoft's
Windows is the dominant desktop operating system, and it enjoys the advantages
described above. Developers using a platform-specific approach tend to develop for the
Windows operating system first, and often for Windows only. As a result, more software
applications are available for Windows users, which makes that platform even more
attractive for customers. This, in turn, reinforces the dominance of Windows, and leads
even more developers to develop software for Windows.
19. Windows' dominance has now reached the point that developers of desktop computer
software have no realistic choice but to support the Windows operating system.
Page 10
III. System Dominance
A. Background
20. The Java technology offers the benefit of freeing software developers from the need to
develop, compile and debug separate versions of their programs for each operating system
and hardware platform that the developers want to support. The Java technology is
intended to make it possible to develop software applications that are not dependent on a
particular operating system or particular computer hardware.
21. What eventually became the Java technology started as a project to examine business
trends in several parts of the computer industry. In the course of this examination, it
became clear that the "platform-specific" problem discussed above occurs in many parts of
the industry. There are many different microprocessors, and many different operating
systems, included in many different types of devices (from computers to games to personal
digital assistants to cable-TV set-top boxes); each requires different platform-specific
software. It became clear that companies participating in these markets would find
attractive a reliable software design that would enable them to create applications that
would work without regard to the underlying processor, hardware, or operating system,
and that would encourage third-party software developers to create applications that
would make the companies' products more valuable. A principal objective of the Java
technology was to meet this need.
Page 11
B. Platforms
23. As seen in Exhibit 3, the Java technology significantly reduces the difficulty of producing
software products for different operating system and hardware platforms. Software
developed using the Java technology (hereafter referred to as "Java-based software,"
"Java-based applications," or "Java-based programs") differs from traditional platform-
dependent software in that it need not interact directly with the specific operating system
or hardware of a given computer.
24. Java-based programs need not run by interacting with a particular operating system's
APIs. Instead, they typically interact with a Java virtual machine ("JVM"), which is an
intermediate software layer that translates the Java-based program for the particular
operating system and hardware platform that the Java virtual machine runs on. In essence,
the Java-based program views the JVM as an operating system, and the operating system
views the JVM as a traditional application.2
Page 12
25. Since a Java Virtual Machine must interact with or "call to" specific operating system and
hardware functions when it runs a program written with the Java language, each JVM
must be written for a particular platform such as Windows/Intel, PowerPC/MacIntosh,
Solaris/SPARC, etc. Nevertheless, once a JVM is developed for a software platform, if
the JVM is fully compliant with the Java specifications (and thus a "compatible JVM,"
which I also refer to as "compatible" or "cross-platform Java technology") it should run
most Java-based programs without the need to recompile or otherwise modify the
programs.3 Likewise, a Java-based program should run on different vendors' JVMs
available for a given platform. Such programs thus have the potential to run on any PC,
other type of computer, or even devices not traditionally thought of as computers (such as
cellular telephones), provided that the machines have compatible JVMs installed on them.
26. For the Java technology fully to achieve its cross-platform objective, all the elements of
the Java technology found on a given system must fully implement and conform to the
Java specifications. The greater the extent to which an implementation of the Java
technology diverges from the standard, the more likely it is that a given Java-based
program will not execute properly on that divergent implementation.
Page 13
27. A principal goal of the Java technology is to assure that a Java-based program -- unlike a
traditional software application -- is no longer tied to a particular operating system and
hardware platform, and does not require the developer to undertake the time-consuming
and expensive effort to port the program to different platforms. As we said in the Preface
to The Java Programming Language, "[s]oftware developers creating applications in Java
benefit by developing code only once, with no need to ‘port' their applications to every
software and hardware platform."
28. As shown on Exhibit 4, creating cross-platform software applications to run on multiple
operating system and hardware platforms is easier, faster, and less costly with the Java
technology. A software developer first uses the Java programming language and APIs to
write sourcecode. This Java-based sourcecode is then converted by a Java compiler into
"bytecode," which is a set of software instructions that can be executed on any compatible
JVM, rather than traditional compiled binary code that works only on a specific operating
system and hardware platform. (I refer to code written with this technology as "Java-
based sourcecode" or "Java-based bytecode," as the case may be.) Testing and debugging
Java-based bytecode for use on multiple platforms and JVMs is much easier because both
the sourcecode and bytecode can be identical for all platforms. While testing Java-based
programs on each JVM they will run on is prudent, this testing is far less burdensome and
expensive than testing traditional software code developed for other platforms.
Page 14
29. Java technology thus has several benefits when compared with traditional platform-
specific software:
a. Using the Java technology reduces the cost of "porting," or modifying a software
product to run on multiple platforms, meaning that developers can support many
platforms with substantially less effort and cost than is necessary when writing
platform-specific code. Thus, the Java technology greatly expands the number of
different platforms that a developer with finite resources can support, while
shortening the time and cost of writing software for different computers and
operating systems.
b. Because the Java technology allows developers to make software applications that
can run on various JVMs on multiple platforms, it holds the promise of giving
consumers greater choice in applications, operating systems, and hardware. The
Java technology has the potential not only to free individual consumers from
concern about whether the software they want to run is supported by a given
operating system, but also to permit corporations and Internet users more easily to
mix different types of computing systems across a network.
c. As more new Java-based programs are developed, distributed and used, new
operating systems may be developed to take advantage of the existing body of
Java-based software. In other words, potential developers of new operating
Page 15
systems and hardware platforms need not be deterred by the absence of platform-
specific programs for their new systems, so long as there is a JVM available to
enable existing Java programs to run on the systems. This may give new operating
systems and hardware platforms a chance to compete in markets previously
dominated by a particular vendor.
d. Java technology will allow different types of computing devices to operate the
same software program and to more easily share software and data, which is
especially important in networks with different computing devices on them. For
example, different machines in a factory could be linked with computer- based
control terminals or even with a manager's hand-held phone.
30. The Java technology is in the process of maturing, and occasionally a developer will
encounter a situation in which the programmer needs to write a portion of a program in a
different programming language in order to access functionality not yet supported in the
Java technology, but which may be available in the underlying ("native") operating system
or hardware. To do this, the Java technology includes a "Java Native Interface" ("JNI").
JNI is a standard Java API that acts as a link between the JVM and the platform-specific
code included in an application to perform the particular operating-system function. JNI
thus gives programmers a way to use native platform functionality with their Java-based
software. For example, one might write C++ language code to get direct operating
Page 16
system support for a scanner, since that function does not yet exist in the Java
technology.4
C. Java Technology is Gaining Recognition Among Software Developers
31. I believe it is clear that the Java technology continues to generate much excitement and
developer interest. Sun's experience with developers reinforces this. Sun's Java
Development Kit ("JDK") is used by software developers to build Java-based programs.
Sun's JDK version 1.1.6 was made available for download via the Web in early April
1998. Although Sun does not have full statistics on the total number of downloads of
JDK 1.1.6 since its release, presently available download statistics indicate that there have
been over 600,000 downloads of the Windows version of JDK 1.1.6 alone since May
1998.
32. Another measure of how enthusiastically developers have embraced the Java technology
can be found in the more than one thousand copies of Sun's Java sourcecode that have
Page 17
been licensed and downloaded from Sun's Web site for evaluation and reference since
Sun's release of version 1.1 of the JDK. Typically, only developers and other computer
professionals who are serious about optimizing their products go to the trouble of
examining sourcecode. Further, more than 100 corporations have executed commercial
sourcecode licenses for the Java Application Environment, which gives them the right to
modify and directly incorporate Sun's Java sourcecode into their own products. These
licensees range from programming tools vendors, such as Inprise, which develop Java-
based tools that their customers use to create Java-based programs, to major software
developers, such as Oracle, Sybase and IBM, which develop Java-based programs for
distribution to their customers.
33. As another measure of developer interest, I understand that most universities that offer
computer majors have courses in programming in the Java language, and that hundreds of
technical books have been written about Java. Sun's annual Java software developer
conference, "JavaOne," is now one of the largest developer conferences in the software
industry.
Page 18
D. The Relationship of Java Technology to the Internet and Web Browsers
34. Because the Java technology is particularly useful for running software that is downloaded
over a network, such as the Internet, we adapted the Java technology to work in
conjunction with web browsing programs known as "browsers." A browser is an
application that, like a JVM, runs on the operating system installed on a user's computer.
It permits the user to access information encoded in hypertext markup language, or
HTML, and other types of content found on the Internet or other networks, and to
navigate around these networks. The browser can interact, not only with the underlying
operating system, but also with other types of programs that can extend and enhance the
browser's capabilities.
35. Java technology in essence permits certain software programs to run within browsers.
Java-based programs can be downloaded from the Internet or other network to a user's
computer without regard to what operating system or hardware is installed. These Java-
based programs can do a host of things such as provide active content (for example a
stock ticker, or a continuously updated summary of the World Series) or other functions
that will appear within the browser.
Page 19
1. inextricable part of an operating system
36. I am quite familiar with web browsers from my work over the past several years
developing the Java technology to be distributed, embedded in, and run upon browsers.
Indeed, I was centrally involved in adapting the Java Virtual Machine so that it can run in
conjunction with a browser, and I therefore needed to develop an understanding of
browser architectures. Furthermore, I was extensively involved in the design of Sun's
HotJava browser.
37. The HotJava browser is a software application that was released by Sun in 1995. At the
time the HotJava browser was developed, Sun contemplated undertaking the revisions and
improvements necessary to maintain it as a competitive product for desktop computers
such as Windows PCs. However, after Microsoft announced that its Internet Explorer
browser would always be given away for free, Sun concluded that it made little business
sense at that time to compete vigorously to sell a consumer browser application to
compete against a product that was being given away for free.
38. In my view, the browser is best understood as a software application, not as a part of a
computer's operating system. This is true both as a matter of function and as a matter of
software design. As a matter of function, browsers perform tasks for the end user that
relate to obtaining and displaying content on the Internet or other networks. Users may
Page 20
wish to choose a particular Internet browser that best fits their needs, or if they have no
need to "browse the Web," perhaps no browser at all.
39. Technically, browsers are treated by the computer like any other application. In virtually
every operating system with which I am familiar, the particular files that enable browsing
are loaded into memory and used in exactly the same way as other software applications.
Even in Windows 98, where Microsoft apparently loads some browser-related files into
memory even when the user may never need that functionality, these files are loaded in the
same way as other software applications. In essence, Microsoft simply shifts the time
required to load the browser code from when it is first needed by the user to every time
the computer boots up.
40. I am aware of no significant technical reason to include a browser in an operating system.
Modern programmers, including operating system developers, design their software code
in a "modular" form, meaning that the code that causes the performance of a number of
individual programming functions may be grouped into "modules" or "objects." The
advantages of modular code development include facilitating work by large development
teams, reducing the cost and effort involved in programming by re-using existing code,
easing testing and debugging, and permitting programmers to modify or add various
modules as needed. The programmer then groups these modules into files that are
shipped as parts of a software release.
Page 21
41. There are disadvantages to adding modules or files to an operating system, particularly
when they are not needed by the end user. Adding additional modules or files may
increase the operating system's need for memory or disk storage, may reduce its
reliability, and may result in slower performance. It also increases difficulties in testing
and debugging, and potentially in customer support calls.
42. In my view, there are no significant efficiencies to be gained by the inclusion by Microsoft
of the web browser in the operating system that could not also be achieved if computer
manufacturers or end users were permitted to install and remove web browsers
themselves. Once a set of files that perform a particular function is created, these files can
be installed on a computer by the computer manufacturer, or in a separately-distributed
software application loaded by end users. Typically, regardless of whether a particular
file is installed on a computer with the original operating system, or separately by a
computer manufacturer, or by an end user installing a program, the computer will operate
in the same manner. For example, there was a time when several PC manufacturers built
their own user interfaces for use with the Windows 3.X/DOS operating system. These
interfaces, from a technical perspective, were capable of being installed and used by
computer manufacturers or end-users.
43. I am aware that Microsoft takes the position that there are technical reasons for making its
web browser (and its JVM) non-removable parts of Windows 98. Speaking as an
experienced operating systems and applications developer, I can think of no significant
Page 22
technological reason for Microsoft to have designed Internet Explorer as a non-removable
component of Windows 98. Standard programming practice would be to specify a
standard interface between the operating system and browsers, so that any browser could
be plugged in at any time to provide functionality. The only possible justification I can
think of for making the browser or JVM non-removable would involve business
considerations unrelated to the merits of system design or to the enhancement of the
performance of the operating system.
44. Microsoft's JVM, the "Microsoft Virtual Machine for Java," is clearly an example of an
installable component. Even in the Internet Explorer 4.0 installation routine for Windows
95, Microsoft's JVM was an optional component that end users with the retail or
download upgrade could choose to install or not. Likewise, it could be removed through
the "add/delete program" function in Windows 95. In Windows 98, however, Microsoft
has made its JVM a mandatory, non-removable component.
2. Important for the Ultimate Success of the Java Technology
45. The ultimate success of the Java technology is dependent on broad distribution of JVMs
that comply with the specifications for the Java technology. Without enough users able to
run Java programs, there will be little incentive for developers to write Java-based
software; without enough Java-based software, the Java technology will be unattractive to
users.
Page 23
46. For Java programs to run on a user's computer, there must be a JVM installed on that
computer. Each computer with a compatible JVM that can be launched by Java-based
programs is in effect another potential user of Java programs.
47. In 1995, a then-new company named Netscape Communications Corporation
("Netscape") became one of the first Java sourcecode licensees, and put Java technology
into its Navigator browser. Since that time, as explained below, many others have
licensed Java technology from Sun for a variety of purposes. However, the overwhelming
majority of JVMs that have been distributed to end users to date were distributed with
Internet browsers, specifically Netscape's Navigator/Communicator, and Microsoft's
Internet Explorer. No other distribution mechanism for JVMs has reached even a small
percentage of the distribution achieved through the distribution of Internet browsers.
48. I believe that the best proxy for measuring JVM distribution is to track the total number of
Internet browsers distributed that include JVMs. The vast majority of such browsers are
either Netscape's Navigator and Communicator (version 2 and above), or Microsoft's
Internet Explorer (version 3 and above).
49. Other means of distributing JVMs have not been nearly as numerically significant. In my
experience, developers which make downloadable Java-based programs normally do not
also download a JVM with such programs because even a compressed JVM with
Page 24
associated class libraries typically ranges from 3 to 8 megabytes in size. Downloading a
JVM of that size would unacceptably slow transmission of the program at speeds available
to most end users today on the Internet. For example, with a typical dial-in Internet
connection, it would take from approximately 15 minutes to an hour longer to download a
program that also distributed such a JVM. Indeed, current popular Java-based programs
that are downloaded over the Internet without also distributing a JVM include Yahoo
Chat, Quicken Quote Tracker, Sabre's QIK-ACCESS airline reservation software, and
NASA's JTRACK satellite tracking system. I know of few, if any, Internet-downloadable
programs that also redistribute a JVM.
50. Unfortunately, as is discussed below, the implementation of the Java technology that has
been distributed by Microsoft since it released Internet Explorer 4.0 in September 1997 is
linked to Windows in ways that undermine the cross-platform promise of the Java
technology. Thus, a sizeable majority of non-Microsoft-dependent JVMs are being
distributed today with Netscape's browser.
IV. Technology to Windows and Foreclosing Distribution of Netscape
51. The benefit of the Java technology's cross-platform compatibility (which I discussed in
greater detail in part III, above) is that it can free developers, hardware vendors, and users
from dependence on any particular operating system. It may therefore be seen as a threat
to Microsoft's Windows PC operating system monopoly.
Page 25
52. Microsoft's actions regarding the Java technology are potentially significant in our
business and I must stay generally familiar with them. I have also read many of
Microsoft's various public statements and publications about the Java technology.
53. Microsoft has done a number of things that have had the effect of reducing the cross-
platform promise of the Java technology.
54. Microsoft has made an incompatible implementation of the Java technology that is not
cross-platform, but instead is dependent on the Windows operating system platform and
Microsoft's proprietary technology. Microsoft has used its ubiquitous operating system to
flood the market with its Microsoft-dependent implementation. Microsoft has taken
actions to limit the distribution of cross-platform Java technology. Microsoft's actions
threaten to make its implementation the de facto standard, thus eliminating the threat
posed by the Java technology to Microsoft's operating system monopoly.
A. Microsoft Introduced An Incompatible Implementation of the Java Technology
55. Microsoft has a limited license to Sun's Java Technology. Microsoft presently ships its
own JVM, called "Microsoft Virtual Machine for Java," with Internet Explorer 4.0 and
Windows. I did not directly negotiate this license with Microsoft, but was involved in
Sun's decisionmaking process to license the Java technology to Microsoft. Sun's purpose
Page 26
in negotiating and executing this license was to achieve the broadest possible distribution
of compatible implementations of the Java technology in Internet Explorer and other
Microsoft products. As explained below, however, Microsoft has designed its
implementation of the Java technology to impair the ability of programs written to that
implementation to run on non-Microsoft platforms, or even to operate properly on the
JVMs sold by other vendors for PCs running Windows.
56. In October 1997, Sun sued Microsoft in U.S. District Court in San Jose, California,
alleging that Microsoft's implementation of the Java technology violated the terms of its
license. In September 1998, there were evidentiary hearings on Sun's motions for a
preliminary injunction against Microsoft on Copyright Infringement and California Unfair
Competition claims. I testified in those hearings.
57. In this statement, I am not addressing the question of whether Microsoft violated the
terms of its agreement with Sun, which is at issue in the other case. I am simply
describing the actions that Microsoft has taken, and the effect of those actions on the
cross-platform promise of the Java technology.
58. Microsoft has done a number of things that damage Java's cross-platform functionality.
Microsoft's conduct threatens to fragment the Java technology into Microsoft and non-
Microsoft versions, such that: (i) programs written to Microsoft's implementation of the
Java technology are dependent on Microsoft's Windows operating systems and other
Page 27
Microsoft technologies; (ii) applications written to Microsoft's incompatible
implementation of the Java technology are unable to run on the JVMs of Sun and its other
Java licensees; and (iii) programs written to compatible implementations of the Java
technology sometimes fail to run on Microsoft's JVM. For example, Microsoft's
incompatibilities include:
a. Microsoft extended the Java programming language in ways supported only by
Microsoft's incompatible implementation of the Java technology. This is
analogous to adding to the English language words and phrases that cannot be
understood by anyone else. Specifically, Microsoft did two things. Microsoft
added support for incompatible "keywords," or additional Java programming
instructions, to its implementation. And Microsoft added to its implementation
support for "compiler directives," or special comments inserted in Java sourcecode
that alter the behavior of the code when it is compiled into Java bytecode. Among
other things, Microsoft's compiler directives permit the Java Virtual Machine to
interact with or "call" proprietary Microsoft Windows APIs. Only Microsoft's
incompatible implementation recognizes these idiosyncratic keywords and compiler
directives. Among other things, some of these extensions prevent programs from
being compiled by non-Microsoft compilers, and all such extensions prevent
programs from running as intended on non-Microsoft JVMs.
Page 28
b. Microsoft omitted from its implementation of the Java technology a standard API
called "JNI," that permits platform-specific software code to interact with Java
code in a program. Instead, Microsoft substituted its own proprietary interfaces,
called RNI, J/Direct, and @COM. By omitting the standard API, Microsoft
prevents developers from writing a Java-based program that can run on every JVM
implementation. If the developer uses JNI, the software will not run on
Microsoft's JVM; if the developer uses Microsoft's proprietary RNI, J/Direct, or
@COM interfaces, the software will not run on any other JVM. Moreover,
Microsoft's proprietary interfaces require the use of Microsoft's development
tools.
c. In the incompatible implementations of its Java technology that it ships in
Windows, Microsoft does not include support for "RMI," a method of sharing
software components, that other desktop implementations of Java technology use.
Instead, Microsoft supports only its proprietary "COM" object architecture in the
Microsoft Java tools and JVM that it distributes. The only way for a person using
Microsoft's tools or its JVM to take advantage of RMI functionality is for them to
download and install the RMI class libraries and RMI compilers from the Internet.
While some technically proficient and knowledgeable developers may be able to
find these RMI technologies on the web, most end users with a Microsoft JVM
will never know of their existence, let alone be able to find, download, and install
them. If a Java-based program that uses RMI is run on a PC with Microsoft's
Page 29
JVM, the program will fail; similarly, if a Java-based program using COM is run on
a non-Microsoft JVM, the program will fail.
d. Until recently, Microsoft's implementation of the Java technology included
modifications of Sun's public class libraries that prevented programs written with
these modifications from operating as intended on non-Microsoft JVMs.
59. In sum, the key parts of the Java technology -- the programming language, the class
libraries and APIs, the compiler, and the JVM -- have been altered in Microsoft's
implementation in ways that impair the cross-platform promise of the Java technology.
60. It is often difficult for Java developers to avoid placing Microsoft dependencies in Java-
based programs, even if they do not use Microsoft development tools. The vast majority
of programs today are not written entirely "from scratch." Much modern software
development depends on re-using pre-existing elements of software code. Developers
supplement their own code by stitching together pre-existing elements of software code.
These pre-existing elements may come from many sources: third-party commercial
software development kits, free downloads from developers' web sites, and even informal
sharing and trading of code within the developer community, just to name a few.
Microsoft dependencies may be embedded in code elements that are not readily apparent
to the developer. As a result, even a developer who is careful not to use a Microsoft
Page 30
dependency in code he writes may find that he has made his program dependent on
Microsoft's implementation because of code he incorporated from elsewhere.
61. Microsoft employees have acknowledged to me that unilaterally extending the Java
language destroys the cross-platform compatibility of Java technology. I attended a
meeting of all the major Java development tools vendors that was called by Microsoft in
February 1997. At that meeting, Microsoft proposed making a number of extensions to
the Java programming language. All of us who attended the meeting -- including
Microsoft -- unanimously agreed that unilaterally extending the Java programming
language would hurt compatibility among Java tools and programs, would injure other
tools vendors, and would damage customers' ability to run a Java-based software product
on whatever platform they wished. One of the Microsoft representatives in attendance
admitted that unilateral language extensions would be detrimental, and said that Microsoft
"wouldn't be cowboys" by unilaterally introducing such extensions in their implementation
of the Java technology.
62. The impact of Microsoft's actions in undermining cross-platform Java technology has
been compounded by the relationship between Microsoft's JVM and its Java-based
development tools. Since only Microsoft tools offer the capability to invoke the
Microsoft-dependent aspects of Microsoft's JVM, developers wishing to write software to
run on Microsoft's JVM (which is being ubiquitously distributed by Microsoft as
discussed below) are thus required to use Microsoft's development tools as well. But
Page 31
when developers use Microsoft's tools for Java-based programming, the programs they
create can encounter great difficulties in running on non-Microsoft JVMs.
63. Microsoft uses its development tools to encourage developers to write Microsoft-
dependent Java-based programs. Microsoft bundles its Java development toolkit in its
Visual Studio development suite, which is the most popular set of Windows development
tools. Microsoft's Java-based development tools are shipped with the company's
incompatible extensions enabled by default. Further, as part of its "support" of
developers, Microsoft publishes and distributes widely many examples of sample Java-
based programming code that can be run only on Microsoft's JVM.
B. Technology and Impeded Distribution of Cross-platform Java Technology
64. I understand that evidence may be offered in this case that will show that Microsoft has
taken actions that have limited the distribution of Netscape's browser. To the extent that
Microsoft has taken such actions, those actions have made, and will continue to make, it
more difficult for the Java technology to achieve the broad distribution necessary to ensure
its success as a cross-platform technology.
65. The preservation of a competitive market for Internet browsers is critically important to
preserving the viability of the cross-platform Java technology. Microsoft's actions injure
not only Sun, but the entire community of Java-based developers, computer users, and
Page 32
potential operating system competitors of Microsoft. I believe that a competitive browser
market would significantly assist Sun and other cross-platform Java-based developers in
getting cross-platform Java technology distributed to end users through the distribution of
non-Microsoft Internet browsers.
66. Microsoft has included its Microsoft-dependent version of the JVM in Windows 98, both
in the version available in retail stores, and in the version it licenses to PC manufacturers
to install in new PCs. These are powerful methods of distributing Microsoft-dependent
JVMs, and they assure that Microsoft-dependent JVMs will be present on a very large
percentage of personal computers.
67. I am aware of no PC manufacturer that is presently shipping a second, compatible JVM on
their Windows systems.
68. Microsoft's forced distribution of Internet Explorer and its Microsoft-dependent JVM
impairs and prevents the distribution of cross-platform Java technology. By forcing
computer manufacturers to bundle both a browser and Microsoft's JVM, Microsoft has
hindered the ability of other browsers with compatible JVMs from getting distribution on
Windows PCs.
69. Microsoft includes its Microsoft-dependent implementation of the Java technology in
toolkits distributed to hundreds of thousands of software developers. Because of the
Page 33
Microsoft dependencies embedded in these toolkits, programs written using the toolkits
can cause Java-based programs to be tied to the Microsoft implementation, undermining
the cross-platform compatibility of the Java technology.
V. Microsoft's Actions Threaten the Cross-Platform Promise of Java Technology
70. The cumulative effect of Microsoft's actions is to create two versions of the Java
technology -- a Microsoft-dependent version, and a compatible version intended to run on
all platforms.
71. The Microsoft-dependent implementation of the Java technology can impair the ability of
Java-based programs to run on other operating systems, or even on non-Microsoft JVMs
on Windows. For example, if developers use Microsoft's additional keywords, compiler
directives or native interfaces, those programs will no longer work properly for users of
non-Windows operating systems or non-Microsoft JVMs.
72. I regularly discuss the issues created by Microsoft's implementation of the Java
technology with software developers, and have probably had hundreds of such
conversations over time. Because of Microsoft's incompatibilities, developers are
beginning to become aware that they may have to write Java-based programs twice — to
the Microsoft-dependent implementation of the Java technology and to the cross-platform
implementation of the Java technology. This is precisely what the Java technology was
Page 34
designed to avoid, and it demonstrates that Microsoft's actions threaten to fragment the
Java technology.
73. If Microsoft's broad distribution of its Microsoft-dependent implementation of the Java
technology in Windows, in Internet Explorer, and in its development toolkits leads Java
developers to use these Microsoft dependencies, the potential of this technology to reduce
the barriers to developing new operating systems will be undermined, and Microsoft's
operating system monopoly will be further enhanced.
74. In short, if Microsoft successfully fragments the Java technology, the cross-platform
benefits to vendors, developers, and users of the Java technology will be damaged, and
any threat that the Java technology poses to Microsoft's dominant Windows operating
system will be neutralized.
Page 35
I declare under penalty of perjury under the laws of the United States of America that the
foregoing is true and correct.
Dated: October 19, 1988
______________/s/________________
Dr. James A. Gosling
FOOTNOTES
1 I have previously testified and provided evidence in another pending case, Sun Microsystems, Inc. v. Microsoft Corp., No. C97-20884 RMW (N.D. Cal.), which I discuss briefly below. Except where I refer to them specifically, I am not addressing in this statement the issues in that litigation.
2 The Java technology includes several parts: (a) there is a Java programming language and a set of Java APIs found in the Java class libraries, which include standard modules of preconfigured software code that ease software development for Java; (b) a compiler, which translates Java-based sourcecode into Java-based bytecode (so that it can be understood by the JVM); and (c) a JVM. How these are used is explained in paragraph 28, below. The JVM is part of a "Java runtime environment" on the user's computer, that consists of not only the JVM, but also a set of the Java class libraries that are used by a Java-based program running on the JVM. The JVM and the Java class libraries must both be on a user's computer in order to run Java code. The term JVM is sometimes used to refer to the entire Java runtime environment.
3 The main exception to this is Java-based software that also includes "native code" which is code that is platform-specific. As I explain in paragraph 30 below, Sun designed a standardized API called JNI to minimize the amount of customization necessary to run a software application on any given platform.
4 The JNI also gives programmers writing native code efficient access to computers that have JVMs installed, by allowing programmers to re-use their proven platform- specific software code in new programs they develop in the Java technology. For example, a database vendor could write a cross-platform Java-based user interface for a database, while continuing to use its pre-existing database engines that were developed for specific platforms. Another advantage of JNI is that one can substitute different JVMs that support JNI on a given platform, and the Java-based code and platform-specific code in a program will both work. Thus, for example, a program with both Java-based code and native Windows code should run on different Windows JVMs from vendors such as Netscape, Sun, IBM, Oracle, or Inprise.
|
U.S. Department
of Justice
