Reply_Declaration_of_Carla_Schroer_in_Support_of_Sun_Microsystems_Motions_for_Preliminary_Injunction_9_10_1998.
 

32. Reply Declaration of Carla Schroer in Support of Sun Microsystems,
Inc.'s Motions for Preliminary Injunction
Legal document in support of Sun's motion to be argued on September 10th,1998.
 

1. I have personal knowledge of the facts contained in this Declaration and, if called as a witness, I could and would testify competently to them.
2. I am employed by Sun Microsystems, Inc. ("Sun") as a Senior Engineering Manager in Sun's Java Software Division. I was hired by Sun in March 1995 and soon thereafter assumed responsibility for all compatibility testing, developer support, and release engineering for Sun's JAVA Technology, as embodied in the JAVA Development Kit ("JDK"). Since 1995, my responsibilities have included the development, execution, and refinement of the tests, tools and procedures necessary to determine whether products incorporating Sun's JDK technology conform to Sun's applicable compatibility test suites, known as the JAVA Compatibility Kit ("JCK").
3. In February 1997, Sun released the JDK 1.1 upgrade of the JAVA Technology. The JDK 1.1 upgrade was accompanied by the JCK 1.1a Test Suite. The JCK 1.1a Test Suite is designed to ensure that all products developed and distributed by Sun's JDK 1.1 licensees conform to Sun's specification of the AAPI as exemplified in Sun's JDK 1.1.
4. The JCK 1.1a Test Suite specifies the set of compatibility tests and requirements each licensee's product must pass in order to pass the JCK 1.1a Test Suite. A true and correct copy of the published criteria for passing the JCK 1.1a Test Suite is attached hereto as Exhibit A. One of the criteria is the requirement that the output of a licensee's compiler must execute properly with a Sun JDK 1.1 virtual machine*.

"Testing Requirements"

The output from your Java compiler implementation (if applicable) must execute properly with a JavaSoft Virtual Machine of the same version as the Java Compatibility Kit you are using."

5. The purpose of the Compiler Output Requirement is to preserve the fundamental goal of compatible implementations of the JAVA programming and runtime environment by ensuring that a licensee's compiler implementation is not tied to, and thus dependent on, its virtual machine implementation. By requiring code compiled on each JAVA Compatible compiler to execute properly on JavaSoft's reference implementation of the JAVA virtual machine, the Compiler Output Requirement serves to ensure that each licensee's compiler will generate output that complies with the Java Language Specification, and will therefore execute properly, not only on its own virtual machine, but on each other licensee's virtual machine as well. If a licensee's compiler generates output that executes properly on its own virtual machine, but fails to execute properly on JavaSoft's JDK 1.1 virtual machine, the compiler implementation is not only incompatible with Sun's reference implementation, but every other JAVA Compatible implementation as well.
6. The conditional clause, "if applicable," means that the Compiler Output Requirement applies only to those licensees who wish to distribute a JAVA compiler implementation. If a licensee wishes to distribute a JAVA compiler implementation that incorporates the JDK 1.1 technology, that compiler implementation must generate output that executes properly on the corresponding JavaSoft reference implementation of the JAVA virtual machine.
7. Microsoft's Software Development Kit for Java ("SDKJ") 2.02 and 3.0, and its Visual J++ 6.0 ("VJ++ 6.0") toolkits each contain a compiler implementation that incorporates JDK 1.1 technology, and that compiler implementation must comply with the Compiler Output Requirement of the JCK 1.1a Test Suite. As I stated in my June 26, 1998 declaration, Microsoft's compiler directives ("@dll," "@com" and "@security") and/or keywords ("multicast" and "delegate") added by Microsoft to the JAVA programming language and JAVA compiler cause the JAVA compiler implementation contained in SDKJ 2.02, SDKJ 3.0 and VJ++ 6.0 to generate output that fails to execute properly with the JDK 1.1 virtual machine. Consequently, Microsoft's SDKJ 2.02, SDKJ 3.0 and VJ++ 6.0 each fail the Compiler Output Requirement of the JCK 1.1a Test Suite.
8. For example, Microsoft's documentation includes a sample program for the @dll.import compiler directive called ShowMsgBox. Exhibit B attached. When this code is compiled with Microsoft's compiler in its default configuration (non-standard language extensions enabled) and the resulting class file is run on Microsoft's virtual machine, a dialog box appears on the screen, indicating that the program has properly executed. Exhibit C attached. If, however, the same class file is run on the JDK 1.1 virtual machine, the program fails to execute properly and the virtual machine generates an error message. Exhibit D attached. When the same program is compiled on the Microsoft compiler with the compiler switch set to /x (non-standard language extensions disabled), the resulting class file fails to execute properly on either the Microsoft virtual machine or the JavaSoft JDK 1.1 virtual machine. Exhibit E attached.
9. I have read the declarations of Microsoft's experts, Michael N. Huhns and Peter Lee, and am familiar with the statements made therein.
10. Both Drs. Huhns and Lee opine that the JAVA compiler implementation in Microsoft's SDKJ 2.02, SDKJ 3.0 and VJ++ 6.0 passes the Compiler Output Requirement. (Huhns Decl., ¶ 10; Lee Decl., ¶ 12-14.) Their opinions are incorrect, because they are predicated on an erroneous interpretation of "execute properly" as that phrase is used in the Compiler Output Requirement.
11. Dr. Huhns states that he interprets the phrase "execute properly" to mean that the output from a compiler must execute as contemplated by the JAVA Virtual Machine Specification and the JAVA Language Specification. (Huhns Decl., ¶10) Dr. Lee states that he interprets the phrase "execute properly" to mean compliance with the JAVA Language Specification's binary compatibility requirements and the class file format requirements of the JAVA Virtual Machine Specification. (Lee Decl., ¶14) Neither interpretation is correct, nor is either interpretation consistent with the plain meaning of the Compiler Output Requirement: the compiled output of a licensee's compiler implementation must execute as intended by the programmer when that compiled code is run on the standard virtual machine implementation contained in the JDK1.1. Each of Microsoft's compiler implementations fails this requirement.
12. As used in the Compiler Output Requirement, "execute properly" means that the compiled JAVA code output of a licensee's compiler must perform the function(s) intended for that code in a manner that conforms with the JAVA specifications when the compiled code is executed on the standard implementation of the JAVA virtual machine contained in JavaSoft's JDK 1.1. The purpose of the Compiler Output Requirement is to ensure that one licensee, such as Microsoft, does not incorporate non-standard language extensions that are not supported on the standard JDK 1.1 virtual machine into its JAVA compiler and virtual machine implementations. Otherwise, were a licensee permitted to incorporate such non-standard extensions into its compiler and virtual machine implementations, it would be able to tie the use of its compiler to the use of its virtual machine, such that code compiled on its compiler would execute properly only on its JAVA virtual machine and not on any other JAVA virtual machine. To prevent this from occurring, the Compiler Output Requirement requires that code written in the JAVA programming language and compiled using a licensee's compiler implementation must execute properly on the standard virtual machine implementation contained in JavaSoft's JDK 1.1 upgrade. If such code fails to execute properly on the JDK 1.1 virtual machine, then the compiler implementation is by definition incompatible with the standard implementation of the JAVA virtual machine and, for that reason, fails to pass the JCK 1.1a Test Suite.
13. As Dr. Huhns and Dr. Lee would construe "execute properly," the Compiler Output Requirement would become a nullity. According to Drs. Huhns and Lee, "executes properly" does not mean function as intended by the programmer. Rather, as they would construe the phrase, it means the standard JDK 1.1 virtual machine must fail to execute compiled code containing Microsoft's non-standard language extensions. According to Drs. Huhns and Lee, so long as the JDK 1.1 virtual machine fails to execute code containing Microsoft's non-standard language extensions, the virtual machine has "properly executed" the non-standard code by failing to do so. What Drs. Huhns and Lee ignore, however, is the fact that the compiled code executes as intended on the Microsoft virtual machine but fails to do so on the JDK 1.1 virtual machine. It is precisely that incompatibility that the Compiler Output Requirement is designed to prevent. Thus, as Drs. Huhns and Lee would construe "execute properly," it would permit Microsoft's compiler to do precisely what the requirement is designed to prevent: compile non-standard extensions that violate the JAVA Language and Virtual Machine Specifications, and that execute properly only on its implementations and no other.
14. To my knowledge, Microsoft is the only JDK 1.1 licensee whose released products fail the JCK 1.1a Compiler Output Requirement. Moreover, Microsoft is the only JDK 1.1 licensee that has implemented new keywords and compiler directives that generate compiler output that will execute properly only on its own virtual machine. Finally, Microsoft is the only JDK 1.1 licensee that has suggested that the "execute properly" test is passed where the licensee's compiler generates output that executes as intended by the programmer only on the licensee's virtual machine, and not on the standard JDK 1.1 virtual machine.
15. On May 7, 1998, I executed the "Declaration of Carla Schroer In Support Of Plaintiff Sun Microsystems, Inc.'s Motion For Preliminary Injunction." As I stated in my declaration, Microsoft had recently released, or was on the verge of releasing, new software products entitled SDKJ 3.0, VJ++ 6.0 and Windows 98, all of which, according to Microsoft, incorporated Sun's JDK 1.1 technology. Consequently, as I stated in my May 7, 1998 declaration, section 2.6(a) of the Technology License and Distribution Agreement required that each of those products pass Sun's JCK 1.1a test suite prior to their commercial shipment. I personally supervised Sun's compatibility testing of Microsoft's SDKJ 3.0, VJ++ 6.0 and Windows 98 products and determined that each of those products failed to pass Sun's JCK 1.1a test suite. (5/7/98 Schroer Decl., ¶¶ 12-25.)
16. After I executed my May 7, 1997 declaration, Microsoft released for the first time the following product upgrades:
1. Internet Explorer 4.01 with Service Pack 1 ("IE 4.01") (released May 20, 1998);
2. Updated SDKJ 3.0 pre-release 1 (released June 1998);
3. Windows 98 as a first customer ship product (released June 25, 1998);
4. SDKJ 2.02 (released June 29, 1998); and
5. VJ++ 6.0 Technology Preview 2 (released July 13, 1998).

On June 26 and July 30, 1998, I submitted supplemental declarations in support of Sun's preliminary injunction motions. As I stated in each of my supplemental declarations, I personally supervised Sun's compatibility testing of each of Microsoft's product upgrades and determined that each of them failed to pass Sun's JCK 1.1a test suite. Attached hereto as Exhibit F is a diagram summarizing over time the JCK 1.1a test failures of Microsoft's Windows 98, Internet Explorer, SDKJ and VJ++ product releases.

17. Pursuant to the March 11, 1996 Technology License and Distribution Agreement between Sun and Microsoft, Microsoft certifies Sun that each product it distributes that implements Sun's JAVA technology passes Sun's compatibility test suite prior to the commercial release of the product. Microsoft has refused to comply with Sun's compatibility testing program. Sun's compatibility testing program is a self-test program that relies upon each licensee to administer the appropriate JCK tests to its products and to pass the required tests prior to the release or distribution of their products. In my experience, Sun's JDK 1.1 licensees customarily inform Sun of any JCK 1.1a compatibility tests their products fail, and discuss with Sun the reasons for such test failures, prior to the commercial release or distribution of their products. Sun has discovered on occasion, subsequent to a licensee's release or distribution of a product, that the product fails one or more valid JCK 1.1a tests. In all instances of which I am aware, Sun has contacted the subject licensee and, with the sole exception of Microsoft, secured its written agreement to modify its product implementation in a current or subsequent release to pass all required JCK tests. After I executed my May 7, 1998 declaration, Microsoft released five new product upgrades. Sun discovered that each of Microsoft's new product upgrades failed Sun's JCK 1.1a test suites only because Sun assumed the burden to test each of Microsoft's new releases. Microsoft continues to refuse to modify its already-released product implementations to pass the required tests contained in the JCK 1.1a test suite.
18. Sun's JDK 1.1 technology is designed to be able to dynamically load native code. Consequently, Sun's JDK licensees are required to implement JNI in each JDK 1.1 product they distribute, and to pass all required JCK 1.1a compatibility tests for JNI.
19. Sun's JAVAOS is a different product designed for a different purpose than Sun's JDK 1.1 technology. JAVAOS is licensed separately by Sun under different terms and conditions than its JDK technology. Because Sun's JAVAOS is specifically designed to preclude the dynamic loading of native code, there is no use for a native method interface in JAVOS, and it does not implement JNI or any other native method interface.
20. All of Microsoft's product releases which incorporate Sun's JDK 1.1 have been required to implement JNI and to pass all valid JCK 1.1a compatibility tests for JNI. As illustrated in Exhibit F hereto, all of Microsoft's product releases in fact have failed to implement JNI, and instead have implemented only Microsoft's non-standard native method interfaces. As stated in my prior declarations, every release of these Microsoft products has failed all 214 valid JCK 1.1a compatibility tests for JNI.
21. I understand that Microsoft contends that Sun granted Spyglass, Inc., a company that licenses both Sun's HotJava browser and Sun's JDK, an exemption from passing the JCK compatibility tests for JNI. Microsoft is apparently confusing the two separate products under license to Spyglass. The HotJava browser is an application written in the JAVA programming language. It does not implement the JDK. It does not have a virtual machine, a compiler or a set of class libraries. Accordingly, the JCK test suites simply do not apply to the HotJava browser application. By contrast, the Spyglass implementation of the JDK must pass all required tests of the applicable JCK test suite, including all required JCK compatibility tests for JNI. Sun has not granted Spyglass any exemptions, and I have no reason to believe that the Spyglass implementation of Sun's JDK 1.1 fails to pass any required test of the JCK 1.1a test suite.
22. I am informed that Microsoft contends that Sun selectively permitted certain other JDK 1.1 licensees to fail specific JCK 1.1a tests, including tests pertaining to JNI, that Microsoft is required to pass. This contention is false. Under each of the license and distribution agreements granted by Sun for the JDK, the right to distribute products that incorporate JDK technology is in all cases conditioned upon the requirement that each product first pass the JCK test suite that accompanied the version of the JDK incorporated in the product.
23. In some instances Sun determines that a particular JCK test is invalid and therefore need not be passed by any of Sun's JDK licensees. The process Sun adheres to for determining whether to exclude a test from the JCK test suite permits any licensee to challenge the validity of a test. If Sun's technical reviewer decides that the test should be excluded, Sun informs its Licensees and updates the appropriate exclude list to reflect the deletion. In each instance Sun has excluded a test from the JCK test suite, Sun has added the excluded test to its "exclude lists," which are published on Sun's licensee website. None of Sun's licensees, including Microsoft, are required to pass the tests identified on Sun's exclude lists. Sun has never selectively granted specific JCK test exemptions to certain JDK licensees, while requiring other licensees to pass the very same tests.
24. I am informed that Microsoft contends that certain email communications between Sun and IBM, and internal Sun email communications, suggest that Sun has selectively granted specific JCK test exemptions to IBM, including special exemptions from passing certain JNI tests. (McMahon Decl., Exhs. 47, 71 and 87) I have reviewed McMahon Decl., Exhs. 47, 71 and 87, and they do not support Microsoft's claims. As the documents indicate, IBM followed the procedure identified above by informing Sun that it believed certain JCK tests were invalid. The single document mentioning JNI states that the JNI tests at issue were on Sun's exclude lists, and therefore did not have to be passed: "Meantime JNI invocation is in the JCK but on the exclusion list, so no compliance problem…" (McMahon Decl., Exh. 71.) The fact that the identified JNI tests were on Sun's JCK exclude lists means that none of Sun's licensees, including Microsoft, were required to pass the excluded tests. Sun has never permitted IBM to fail any JCK tests, including tests pertaining to JNI, that Sun required its other licensees to pass.
25. Microsoft similarly has availed itself of the same Test Exclusion Process in instances when Microsoft's products have failed JCK tests that Microsoft has contended were invalid. Pursuant to Microsoft's requests, Sun has on several occasions declared specific JCK tests invalid and added them to the exclude list. On other occasions, Sun has rejected Microsoft's request to add a test to the exclude list after Sun determined that the challenged test was valid.
26. In my declaration of July 30, 1998, I stated that I personally supervised Sun's compatibility testing of SDKJ 2.02, together with the RMI class files downloaded from the Microsoft Website, to determine whether SDKJ 2.02 version 4.79.2424 passes the JCK 1.1a test suite. SDKJ 2.02 version 4.79.2424 includes compiler version 1.02.7315. Among other test failures, I stated that the SDKJ 2.02 compiler version 1.02.7315 fails two required compiler tests:
1. "lang/PKGS/pkgs006/pkgs00601/pkgs00601.html" ("Test 601"); and


2. "lang/PKGS/pkgs020/pkgs02003/pkgs02003.html" ("Test 2003").
27. I have read the August 5, 1998 Declaration of Peter H. Golde, a Microsoft software design engineer whose primary responsibility is developing and testing compilers included in Microsoft's developer toolkits. Mr. Golde does not dispute the validity of Test 2003 or Test 601. Mr. Golde states that, subsequent to my July 30, 1998 declaration, he ran Test 601 and Test 2003 on Microsoft's SDKJ 2.02 compiler, and that he agrees the SDKJ 2.02 compiler fails Test 2003. (Golde Decl., ¶ 4.) Mr. Golde does not contend that Microsoft ever proactively disclosed this test failure to Sun.
28. Mr. Golde claims, contrary to my July 30, 1998 declaration, that the SDKJ 2.02 compiler passes Test 601. (Golde Decl., ¶ 3.) Mr. Golde's claim is incorrect, and is likely based on improper execution of Test 601 or erroneous interpretation of the test results. Test 601 is conducted by simultaneously compiling two test source files, "pkgs00601.java" and "pkgs00601/pkgs00601c.java," on the compiler being tested. Test 601 is a "negative" test, meaning that the test is failed if the compiler generates a class file rather than generating an error message. Conversely, Test 601 is passed if the compiler does generate an error message when the test source files are compiled. To execute Test 601 correctly, one must compile both test source files simultaneously. The test is executed properly when the JCK 1.1a test harness is used. The failure to compile both test source files simultaneously, or the failure to use the JCK 1.1a test harness, will cause the test to generate output that does not serve as a reliable indication of the test results.
29. To verify my earlier conclusion that Microsoft's SDKJ 2.02 compiler version 1.02.7315 fails Test 601, Sun re-executed the test under my personal supervision in conformance with the required procedures for executing the test correctly. Again, the SDKJ 2.02 compiler failed Test 601 in that it failed to generate an error message when the "pkgs00601.java" and "pkgs00601/pkgs00601c.java" source files were simultaneously compiled.

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

Executed August 14, 1998.

Carla Schroer

*As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.