IN THE UNITED STATES DISTRICT COURT

FOR THE DISTRICT OF COLUMBIA

UNITED STATES OF AMERICA,

Plaintiff,

v.

MICROSOFT CORPORATION,

Defendant.

Civil Action No. 98-1232 (TPJ)

STATE OF NEW YORK ex rel.

Attorney General DENNIS C. VACCO, et al.,

Plaintiffs,

v.

MICROSOFT CORPORATION,

Defendant.

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

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.

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.

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.

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.

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.

III.	The Cross-Platform Potential of the Java Technology Threatens Microsoft's Operating 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.

B.	Java Technology Enables the Development of Software That Works Across 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

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.

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.

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

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.

1.	There is no convincing technical justification for making a web browser an 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 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.

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 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.	Broad Distribution of Web Browsers with Compatible JVMs is Critically 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.

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 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.	Microsoft's Response to the Threat of the Java Technology: Linking Incompatible Java 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.

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

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 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 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 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.	Microsoft's Actions Have Promoted Distribution of Microsoft-Dependent Java 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 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 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 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.

I declare under penalty of perjury under the laws of the United States of America that the foregoing is true and correct.

Dated: October ___, 1988

______________________________

Dr. James A. Gosling