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.
|