McDONALD & QUACKENBUSH, P.S.
T. McDonald (WA State Bar #5260)
Karl J. Quackenbush (WA State Bar #9602)
3300 First Interstate Center
999 Third Avenue
Seattle, WA 98104
ORRICK, HERRINGTON & SUTCLIFFE LLP
Terrence P. McMahon (#71910)
G. Hopkins Guy, III (#124811)
William L. Anthony, Jr. (#106908)
1020 Marsh Road
Menlo Park, CA 94025
Allen Ruby (#47109)
60 South Market Street, Suite 1500
San Jose, CA 95113
Thomas W. Burt (WA State Bar #9613)
Linda K. Norman (WA State Bar #15369)
One Microsoft Way, Bldg. 8
Redmond, WA 98052
Attorneys for Defendant Microsoft Corporation
UNITED STATES DISTRICT COURT
NORTHERN DISTRICT OF CALIFORNIA
SAN JOSE DIVISION
SUN MICROSYSTEMS, INC., a Delaware corporation,
MICROSOFT CORPORATION, a Washington corporation,
NO. C97-20884 RMW (PVT) ENE
DECLARATION OF CHARLES FITZGERALD
CHARLES FITZGERALD makes the following declaration on personal knowledge:
1. I have been employed by Microsoft since 1989. I have been working as a Program Manager with Microsoft's Java Runtime team since October 1996.
2. Since October 1996, I have been Microsoft's primary spokesperson for Microsoft's implementations of Java technology, including the Microsoft Software Development Kit for Java ("SDKJ") and Microsoft's Java support in Internet Explorer ("IE"). My job is to communicate with Microsoft's customers, including independent software developers who use the Java programming language, concerning Microsoft's products and product plans. Because software developers are a key constituency for Microsoft, I spend a large amount of my time communicating with and listening to them. As part of my duties, I regularly read the trade publications that are relevant to Java development and the Java market. I attend Java developer's conferences around the country, give presentations about Microsoft's Java support to Java developers and to our customers, and monitor Internet news groups and mailing lists focused on Java development. Microsoft also maintains worldwide web sites devoted to Microsoft's Java products where we provide information and news concerning our products.
3. Microsoft and Sun directly compete for the loyalty of Java developers and customers. As part of my duties, I keep track of Sun's marketing and other public statements concerning their Java products, including Sun's software development kit ("JDK"). I am often asked to give Microsoft's responses to Sun's marketing.
4. In IE version 4 ("IE4") and Microsoft's SDKJ version 2 ("SDKJ
2.0") Microsoft implemented most, but not all, of the functionality of Sun's JDK 1.1. We decided not to support Sun's native interface ("JNI") and not to include Sun's Remote Method Invocation package ("RMI"). We have been very clear with developers and other customers that we do not include these aspects of Sun's JDK 1.1. We had publicly stated that we would not provide JNI and RMI before IE4 and SDKJ 2.0.
5. We released the final version of IE4 on our worldwide web site on September
30, 1997. We released SDKJ
2.0 on approximately October
7, 1997. On our Java developer's site we posted a document entitled "Questions and Answers." A copy of this document is attached as Exhibit
A. This Q & A lets developers know why we chose not to support JNI or include RMI in our products. The fact that Microsoft does not include JNI and RMI has also been widely discussed in the trade press and on the worldwide web at sites which focus on Java development.
6. At the time we released IE4, we also made Sun's RMI classes available for download from our Microsoft Developer Network web site. The download was made available at the site on the web that includes other code available for download by software developers. The RMI package could be found by searching our web site. Additionally, Microsoft publicized the site of the download in a press release in conjunction with the release of our SDKJ 2.0, a copy which is attached hereto as Exhibit
B. We also added pages to our worldwide web site (www.microsoft.com/java) which provided a more direct link to the RMI file. Since the first posting of the RMI files at our site, approximately 1,300 copies have been downloaded.
7. I am generally familiar with the enhancements made by Microsoft in the Java classes included in SDKJ 2.0. The majority of these changes are undocumented and only intended for internal use by our Java virtual machine implementation. We have not publicized them so that developers will not use these calls in developing applications. Other public changes in the Java classes which are specific to the Windows platform are documented in the portion of the SDKJ 2.0 documentation designed specifically for developers who wish to take advantage of developing applications for the Windows platform. These changes are not documented in the portion of the SDKJ documentation that contains documentation provided by Sun. This Sun documentation is included unmodified in our SDKJ documentation.
8. I have read Sun's motion papers in which it is suggested that a developer might be confused by the fact that our products do not incorporate JNI, RMI and include added methods and fields to the Java classes. Sun also suggests that developers do not understand that the Java classes in Microsoft's products have been enhanced, and that this will cause them to unknowingly write Java programs which will not be portable across platforms without changes. These theories simply do not comport with the real world of Java developers. Java developers who write programs in accordance with Sun's documentation would never see any of these changes and would not be confused. Java programmers using the Microsoft-supplied documentation for the Microsoft virtual machine for the Win32 platform would understand that there were Windows-specific enhancements to the Java classes. I have never heard of a Java developer being confused or misled by our products in the way Sun describes. I have never had a developer tell me that they mistakenly invoked Win32 specific aspects of our SDKJ while trying to write a "cross-platform" application. If such a thing had happened, I am certainly the person most likely to hear about it since I am the point person for most Microsoft communications to Java developers, and for feedback received from Java developers. While some Java developers have complained that we don't support JNI or include RMI, or asked us why we made the choices, I have never had a developer tell me that he or she was fooled by the fact that we do not support these. I have never had a developer complain that our changes to the Java classes misled them into using Windows-specific aspects of our products when they did not intend to do so. I am in a position to know if Java developers are being misled or confused, and based on my experience, I do not believe such confusion exists.
9. In fact, Java developers have embraced IE4 and Microsoft's Java virtual machine implemented in that product. Our IE4 Java virtual machine has been critically acclaimed as the best, fastest and most functional Java virtual machine available. Attached as Exhibit
C are a sample of some of the reviews of Microsoft's Java implementation. Typical is the Sept.
29, 1997 edition of PC Week which noted "all the JDK 1.1 applets we tested with the IE4 release candidate worked. On the other hand, in our test of [Netscape] Communicator, it failed to run several JDK 1.1 applets." The acceptance of the IE4 Java implementation by the market is not surprising. In developing the product we devoted substantial time and energy in testing our Java implementation running hundreds of different Java applets on the world wide web. Microsoft's real-world Java application compatibility has also been verified in the trade press. See, e.g., Exhibit
D: "In our tests to date, we've found that Internet Explorer has the best implementation of Java on Windows thus far."
10. Sun's motion papers describe Sun's vision of "write once, run anywhere." I have heard Sun articulate this marketing message many times. However, in the real world of Java developers it is well known that "write once, run anywhere" is not a reality. There are numerous implementations of Java virtual machines available on various operating system platforms. All have incompatibilities with each other. This fact has also been widely reported in the trade press, and examples are attached as Exhibit
E. The different implementations are necessary in order to make the Java technology function by adapting Java to the underlying hardware and operating system of a particular platform. In order to write applications that are intended to be strictly "cross platform," the developer must sacrifice performance and functionality because he or she is constrained to use a "least common denominator" approach to Java application development. Very few software developers choose to do this because they prefer to create software that is as fast and functional as possible on a given platform.
I declare the foregoing to be true and correct under penalty of perjury under the laws of the United States of America.
Dated this 5th day of February 1998, at Redmond, Washington.