Statement Of Dr. James A. Gosling : U.S. V. Microsoft Corp. And State Of New York, Ex Rel. V. Microsoft Corp.

Download the WordPerfect version
View Exhibits (PDF format)


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.

Updated August 14, 2015