- I have personal knowledge of the facts contained in this declaration and, if called as a witness, I could and would competently testify to them.
- I previously submitted declarations in this action on November 17, 1997, November 25, 1997, February 13, 1998, and May 12, 1998. I submit this declaration now to address issues raised in Microsoft's August 7 opposition papers.
Microsoft's Non-Conforming Keywords
- Dr. Huhns asserts (Huhns Decl. ¶¶ 54-56) that the JAVA Language Specification (JLS) does not prohibit the unilateral introduction of additional keywords that are not specified in the JLS. Similarly, Dr. Lee asserts (Lee Decl. ¶12) that Microsoft's new keywords ("delegate" and "multicast") are compatible with the JLS. I disagree with these assertions. The preface to the JLS states unequivocally that its authors intend to specify the behavior of every language construct "so that all implementations of Java will accept the same programs." (Exh. A, at xxiii.) Moreover, Section 3.9 of the JLS lists all those character sequences that "are reserved for use as keywords and cannot be used as identifiers." A reasonably competent programmer will understand these statements to mean that all remaining character sequences are available for use by the programmer as identifiers, that the set of reserved keywords and the set of identifiers are mutually exclusive, and hence that (barring a future modification to the JLS) the set of keywords is closed.
- Dr. Huhns goes on to assert (Huhns Decl. ¶56) that "any sequence of Java letters and digits" not reserved as a keyword may be used by both programmers and implementers for their own purposes and that the JLS does not prohibit individual compiler implementers from reserving new keywords. However, a character sequence cannot be both reserved for use as a keyword and available for use as an identifier by programmers. If a compiler vendor had the freedom to reserve additional character sequences as keywords, any program that used such a character sequence as an identifier (which is permitted by the JLS) would not compile on that vendor's compiler. Programmers cannot simply avoid the use of character sequences reserved by the various compiler vendors, because if vendors are free to reserve sequences ad lib, a programmer cannot anticipate what sequences might be reserved by vendors in the future. Thus the freedom asserted by Dr. Huhns makes it impossible even in theory for programmers to produce code that will compile properly on all "compatible" JAVA compilers. The JLS is designed precisely so as to avoid this situation. A more reasonable interpretation of the JLS is that any character sequence not appearing on the JLS's keyword list is available for use as an identifier by programmers and not as a new keyword by individual compiler vendors.
- I am also puzzled by Dr. Lee's conclusion (Lee Decl. ¶12) that Microsoft's keywords do not create incompatibilities between Microsoft's products and Sun's specifications. As noted above, by incorporating support for two new keywords into its products, Microsoft renders these products non-conformant with the JLS. In particular, the Microsoft JAVA compiler accepts program source code that uses the non-standard syntax Microsoft created for using these keywords; JLS-conformant compilers will reject such source code. Furthermore, when the Microsoft compiler compiles such source code in the compiler's default configuration, the compiler produces binary versions of these programs that embody the non-conformant semantics associated with these keywords.
- The incompatibilities created by these keywords manifest themselves in two fundamental and indisputable manners: (1) the source code of programs that utilize these keywords in accordance with Microsoft's specifications will, to the best of my knowledge, compile correctly only on a Microsoft compiler and will not compile correctly on any compiler that implements the JAVA language as specified in the JLS; and (2) when Microsoft's compiler compiles the source code of programs that utilize these keywords, the compiled output will, to the best of my knowledge, execute correctly only on MS's JAVA runtime environment, and not on any conforming JAVA runtime environment, unless that environment is extended by the addition of two special JAVA classes ("com.ms.lang.Delegate" and "com.ms.lang.MulticastDelegate") that are required to support these keywords.
Microsoft's Non-Conforming Compiler Directives
- Contrary to the opinions of Drs. Huhns (Huhns Decl. ¶54) and Lee (Lee Decl. ¶12), the compiler directives added by Microsoft (the "@dll", "@com" and "@security" categories of compiler directives) do violate the JLS. Microsoft specifies these directives as paragraph tags embedded inside documentation comments. As noted in Sections 3.7 and 18.4 of the JLS (Exh. B), documentation comments are a form of source-code comments. Source-code comments, by definition, are not permitted to alter the semantics of the program in whose source code they are embedded. Yet, as detailed below, Microsoft's compiler directives do alter the semantics (behavior) of the class in whose source code they appear.
- Drs. Huhns (Huhns Decl. ¶55) and Lee (Lee Decl. ¶43) observe that Sun has implemented a compiler directive—the @deprecate compiler directive—as a paragraph tag embedded in documentation comments. However, unlike the Microsoft compiler directives, the @deprecate directive does not alter the behavior of the class in whose source code it appears. While the @deprecate compiler directive can cause the Sun JAVA compiler to print a warning under certain circumstances, under no circumstances does use of the @deprecated directive alter the behavior of the class in which it is embedded.
- In addition to contravening the JLS, Microsoft's compiler directives also violate the JAVA Virtual Machine Specification (JVMS). Dr. Huhns argues (Huhns Decl. ¶¶59-60) that the binary files produced by the Microsoft compiler are fully consistent with the binary file format specified in the JVMS, even though when Microsoft's compiler compiles a program that contains one of Microsoft's non-standard compiler directives, the compiler inserts non-standard attributes into the binary files that it produces. Dr. Huhns notes that any JAVA virtual machine* implementation that does not recognize these non-standard attributes must, according the JVMS, silently ignore the unrecognized attribute. However, this does not imply that a compiler may freely insert non-standard attributes into the JAVA binary files that it produces. The JVMS does not permit compilers to insert any non-standard attribute that is intended to alter a program's semantics: the only permissible non-standard attributes are ones that do not alter the program's behavior. This is what permits virtual machines as a whole to silently ignore such attributes: they can safely ignore such attributes precisely because these attributes are not permitted to alter program semantics. However, use of Microsoft's compiler directives in a class's source code causes Microsoft's compiler to insert non-standard attributes into that class's binary file, and these attributes alter the class's semantics when executed by the Microsoft virtual machine. Hence, Microsoft's compiler directives violate the JVMS.
- On the other hand, Dr. Lee argues (Lee Decl. ¶¶40-42) that addition of non-standard attributes into JAVA binary files is permitted so long as the semantics of class and interface types is unaffected; he then concludes that Microsoft's attributes don't violate the JVMS because they don't alter the semantics of class or interface types. However, one can easily construct a class type that achieves its intended semantic effect, in part, because the JAVA virtual machine (in particular, Microsoft's virtual machine) that executes the binary file recognizes and processes the information in Microsoft's non-standard attributes. Thus, given that the presence of these attributes in a class's binary file is integral to that class achieving its semantic effect (upon execution of its class file), these attributes can reasonably be considered to alter the semantics of the class type.
- Dr. Lee states (Lee Decl. ¶15) that "Dr. Deutsch is incorrect in stating that a compiler which does not implement Microsoft's compiler directives will reject or misinterpret any programs written using Microsoft's compiler directives." Non-Microsoft compilers will not reject such programs, but they will misinterpret them: when source programs containing those compiler directives are compiled on non-Microsoft compilers, those non-Microsoft compilers will simply ignore these directives, and so when the compiled output is run on a virtual machine (whether a Microsoft virtual machine or a non-Microsoft virtual machine), the program will not execute as intended by the developer (who wrote the program so that the compiler directive would have effect, not be ignored).
The Adverse Effect and Purported Necessity of Language Extensions
- I am puzzled by Dr. Huhns' statement (Huhns Decl. ¶57) that the JLS does not require source-code compatibility. On the contrary, one of the primary purposes of a language specification such as the JLS is to promote the compatibility of source code. I am equally puzzled by Lee's contention (Lee Decl. ¶5) that tool developers, ISVs and customers are not harmed by the fragmentation resulting from MS's keywords and compiler directives. Indeed, the former project leader of the team responsible for implementing Microsoft's JAVA class libraries and JAVA virtual machine, Ben Slivka, stated in response to a question regarding language extensions by individual vendors (Slivka Depo. 310: 9-13):
Q. What is it about divergent implementations that's bad for customers?
A. It forces them to choose a particular compiler or tool, and it doesn't give them enough flexibility to switch between different development tools.
The JLS is designed to prevent precisely this type of fragmentation and its adverse effects.
- Dr. Lee's example (Lee Decl. ¶4) regarding a hypothetical word processing application illustrates the problems and incompatibilities introduced by MS's language extensions. Lee says:
"...if IBM wrote a bug-free word processing application tomorrow in the Java programming language and compiled it using the Sun Java compiler, that program would run on the Microsoft Java Virtual Machine. If the same word processing application were compiled using the Microsoft Java compiler, it would run on the Sun Java Virtual Machine."
If that same application were written using Microsoft's non-standard keywords and compiler directives, the compatibility cited by Dr. Lee would disappear: the program wouldn't compile on a non-Microsoft compiler, and, when compiled on a Microsoft compiler, the compiled output wouldn't execute in the manner intended by the programmer on any non-Microsoft virtual machine.
- Dr. Lee (Lee Decl. ¶¶13, 26-27, 32) points out that vendors of compilers for conventional languages such as C++ have been known to add non-standard language extensions. One may argue as to whether or not the resulting incompatibilities between compiler products and the costs these incompatibilities engender outweigh the benefits in any given case. However, unlike all such languages and their specifications, the JAVA language and the JLS were designed in part specifically to eliminate the problems of incompatible language "dialects." Given the uniqueness of Java's objective of cross-platform and cross-implementation compatibility, and the need to have all implementers conform to a standard in order for that goal to be achieved, language extensions must occur through only a controlled and managed evolution of the standard. The development and introduction of Inner Classes is an example of one such standardized extension to the JAVA language. I would note that, to the best of my knowledge, all JAVA compiler vendors other than Microsoft have implicitly recognized this necessity by refraining from extending the JAVA language, including vendors such as Borland who in the past have readily introduced non-standard extensions in their language products. Moreover, even when a vendor of conventional languages introduces non-standard extensions into a language product, the vendor typically qualifies the name of its new language dialect so as to avoid confusion with the standard language. For example, when Borland extended the Pascal language, Borland called this dialect Turbo PascalTM to distinguish it from standard Pascal.
- I also disagree with Dr. Lee's assertion (Lee Decl. ¶32) that, "Any reasonably competent software developer would expect language extensions in a compiler, and would expect a mode switch to enable and disable them." Rather, given the cross-platform and cross-implementation objectives of the Java technology, any reasonably competent JAVA programmer would expect that any extensions to the JAVA language would occur through the evolution of Sun's published standards, so that all vendors would implement such extensions in a uniform and standard manner that preserved the cross-platform and cross-implementation properties of the Java technology.
MATERIAL REDACTED
MATERIAL REDACTED
MATERIAL REDACTED
Failure of Microsoft's Compiler to Pass the JCK Test Requirements
- I have read Carla Schroer's declaration in which she discusses the JCK 1.1a Test Requirement that the output of any licensee's JDK 1.1compiler must execute properly on a JDK 1.1 virtual machine. I agree with her conclusion that SDKJ 3.0 and VJ++6.0 fail this JCK 1.1a requirement; the facts do not support the opinion of Dr. Huhns (Huhns Decl. ¶¶59-60) to the contrary. Specifically, there is no support in fact or logic for the notion that compiler output that runs only on Microsoft's virtual machine, and fails to run on any JAVA-Compatible virtual machine from any other vendor, nonetheless "executes properly" on the non-Microsoft virtual machines. Developers intend programs to run without errors impeding and preventing their progress. Any program that terminates abnormally with an exception (software-generated error indication), or fails to carry out part or all of its normally expected function because of an exception, when one attempts to run it on a JDK 1.1 Virtual Machine cannot be said to "execute properly" on that Virtual Machine.
- Indeed, Dr. Huhns concedes (Huhns Decl. ¶¶35-36) that "a Java program will be unable to execute correctly" when it is "missing anticipated functionality." He concludes (Huhns Decl. ¶60), however, that this failure is "not the result of the existence of compiler directives or keywords. It is the same ‘incompatibility' that results anytime a Java program requests a method from a class library that is not present on the Java Virtual Machine implementation executing a program." Dr. Huhns is mistaken in this regard. It is not the absence of standard functionality or the absence of any method from a class library that causes certain output of Microsoft's compiler to fail to execute properly on the JDK 1.1 virtual machine—in particular, the output generated by Microsoft's compiler when it compiles source code containing one of Microsoft's non-standard compiler directives. Rather, the failure of such output to execute correctly is caused by the fact this output contains non-standard attributes that are not recognized, and hence are silently ignored, by the JDK virtual machine, typically resulting in the virtual machine being forced to halt execution and raise an exception, because it cannot implement the program's semantics.
- The Compiler-Output Requirement noted in the Schroer declaration tests for compliance with both the JLS and the JVMS. Microsoft's compiler directives demonstrate the need to establish requirements that test for compliance with both specifications. When the JLS is violated in certain ways (as occurs when a compiler recognizes non-standard compiler directives that are embedded in documentation comments and processes these directives in such a way as to alter the semantics of the resulting binary file, in violation of JLS), the resulting violations manifest themselves not in the operation per se of the non-compliant compiler, but in an improper coupling between a specific compiler implementation and a specific virtual machine implementation, such that the compiler's output will execute properly only on a single virtual machine, and will not execute properly on other virtual machines. Testing compiler output by executing it on a compliant virtual machine can assist in uncovering such latent errors.
- I have also read MS's contention (Copyright opposition at 3:25-26) that the Compiler Output Requirement is merely "implied" by Sun's JCK 1.1a documentation. This contention is incorrect. Having reviewed the document entitled "Testing a Java Implementation" (Exh. D) that is shipped with the Java Compatibility Kit, I note that the fifth bullet item from the section on "Testing Requirements" states explicitly:
"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."
I have also reviewed pages 181-190 of the Kory Srock deposition, in which he acknowledges this requirement (Srock Depo. 184: 12-20) (Exh. E).
Non-Compliant Compiler Modes
- Drs. Huhns (Huhns Decl.¶58) and Lee (Lee Decl. ¶¶30-31) both argue that Microsoft's compiler is compliant with the JLS and the JVMS because it has a "mode" that causes the Microsoft compiler to operate in a compliant manner. Further, they both note that compiler vendors often implement more that one "mode" in which their compilers can be configured to operate, and that such "modes" are sometimes used to enable or disable the compiler vendor's language extensions. In my opinion, it is not reasonable to require that a programmer of ordinary competence who sets out to develop JAVA programs using a purported JAVA compiler become aware of "modes" of that compiler: a JAVA compiler should accept the JAVA language as defined by the JLS, without having to be instructed to do so. I would further note that I know of no other JAVA compiler vendors that offer such an "extension mode." This is not to say that additional, explicitly selectable compiler modes will never have any utility in a JAVA compiler. Modes of this kind that cause a given compiler to adhere to earlier versions of the JLS can be useful in maintaining backwards compatibility with older code that was written in accordance with earlier versions of the JLS. Unlike the Microsoft "extension" mode, however, such "backwards-compatible" modes wouldn't necessarily undermine binary or source-code compatibility.
Native Method Interfaces
- In my opinion, Dr. Lee (Lee Decl. ¶¶17, 48) and Dr. Huhns (Huhns Decl. ¶¶6, 8, 47) are incorrect in their statements that it is not necessary, in order to conform to the JVMS, for a Java Virtual Machine to provide a means for external native code to communicate with the Virtual Machine. I agree with the statements (Exh. F) of Tim Lindholm, co-author of the JVMS, that "The presence of a native method interface is covered and necessitated by the Virtual Machine Specification" (Lindholm Depo. 252: 19-21) and that "The fact that there can be native methods … presupposes … the existence of an interface that actually enables that to happen." (Lindholm Depo. 254: 23 – 255: 1)
- It is also my opinion that contrary to the claim made in the Copyright opposition (15:10-16:16), the inclusion of Sun's JAVA Native Interface ("JNI") as a public interface to the JAVA Runtime Interpreter is neither arbitrary nor unconstrained. As noted above, the JVMS requires the presence of a native method interface so that programmers can compose portions of their programs in languages other than JAVA. Only on those platforms where no native (non-JAVA) binary code can be expected to exist (e.g., in a system built on hardware that is designed to directly execute only JAVA binary code) would it be unnatural for a JAVA virtual machine implementation to include a native method interface. Given that a native method interface enables programmers to construct hybrid programs consisting of both JAVA binary code and native binary code, it is natural to expect a native method interface to provide a mechanism for JAVA code to access native code and vice versa.
- I find misleading Microsoft's assertions that "JNI is not a Java interface" (Copyright opposition 9:11), that JNI is "an interface for programming in languages other than Java" (Copyright opposition at 4:22-23), that "JNI is a native programming interface not a Java programming interface" (Copyright opposition at 10:15-16), that JNI is "a non-Java, ‘native code' interface not intended for Java programmers" (UC opposition at 2:20-21), that "JNI is simply a mechanism that can be used by non-Java programmers" (Lee Decl. ¶49), that "Sun's Java Native Interface (‘JNI') is not a Java programming interface, it is a native programming interface intended to be used by programmers developing native code programs" (Huhns Decl. ¶5). As does Microsoft's Raw Native Interface ("RNI"), JNI allows application writers to write hybrid programs that combine Java source code and native source code. JNI is the interface between those two sets of code, enabling the Java code to invoke and exchange data with the native code, and enabling the native code to invoke and exchange data with the Java code.
- As I explained in my earlier declaration, the JAVA technology has been designed to achieve the greatest level of portability that is technically feasible. For programs that don't invoke native methods, that means binary and source compatibility across platforms. For programs that do invoke native methods, that means source code compatibility across platforms, and binary compatibility across all implementations on the same platform.
- In its Unfair Competition Opposition at 20: 9-12, Microsoft mischaracterizes my declaration: "Deutsch submits that the primary goal is ‘binary compatibility of native method libraries across all Java VM implementations on a given platform.'" I did not state that the primary goal of "compatibility" was "binary compatibility of native method libraries across all Java VM implementations on a given platform." What I stated was that this was the primary goal of "JNI." This is why JNI achieves the second (binary) type of compatibility, but Microsoft's native method interfaces do not.
- I disagree with Dr. Huhns' assertion (Huhns Decl. ¶4) that only "A Java programmer who is not concerned with cross-platform compatibility can use the Java programming language to access and use functionality written in another programming language." JAVA's design goal of cross-implementation compatibility addresses hardware, operating system, and JAVA virtual machine differences: there are important examples of native code that are in fact usefully portable across all these differences, but more importantly, even native code that is particular to a given operating system and hardware platform can and should be portable across JAVA virtual machines (see email from Gordon and Longabaugh in 8/21/98 Armstrong Reply Decl., Exhibit 5). By defining JNI, a standard interface between native code and all compliant JAVA virtual machines (i.e., those virtual machines implemented on hardware and operating system platforms where accessing non-JAVA code is possible), Sun is providing for two forms of compatibility: (1) source-code compatibility between those portions of native-code programs that directly utilize JNI and any compatible virtual machine, regardless of platform; and (2) on a given platform, binary compatibility between programs that include native code and all compatible virtual machines. Furthermore, standardizing the native method interface has value even for authors of native code that does have hardware or operating systems dependencies. Such standardization reduces the amount of work required to port such code to a different hardware or operating-systems environment. In particular, the programmer that utilizes a standard native method interface will not have to rewrite those portions of his code that access that interface when performing the port.
- In my earlier declaration (5/12/98 Deutsch Unfair Competition Decl.), I stressed that the harm caused by Microsoft's refusal to implement JNI arose from the fact that a single program could not run on all different JAVA virtual machine implementations on the same platform. MS's opposition papers never squarely address that point. Instead, they contend that because programs invoking JNI (or any other native method interface) cannot run cross-platform, Sun cannot be harmed by the exclusion of JNI. On the contrary, native methods that can execute with any conforming virtual machine implementation increase the usefulness of JAVA technology overall, so there is great utility to Sun and its licensees of having the same programs execute on all virtual machines on a given platform.
- Dr. Huhns states (Huhns Decl. ¶7), "Whether or not a Java program that requests access to a native method will execute with a given Java implementation might be a function of whether the native method is available on the system, but it is not a function of what native code interface was selected or assumed by the Java programmer, because no selection or assumption can be made." He further states (Huhns Decl. ¶9), "Whether or not such a program will run on any Java Virtual Machine implementation is dependent upon whether any native methods intended to be used by the program are available to the Java Virtual Machine implementation. It is not dependent, however, on the native programming interface used in developing the native method." These statements are incorrect because they fail to consider that for a native method to be "available" to a JAVA program, it must be written using a native method interface that is compatible with the JAVA virtual machine implementation. A native method that uses JNI, for example, will not execute properly with Microsoft's JAVA virtual machine, regardless of whether the native method is physically present on the system in compiled form, precisely because Microsoft's virtual machine does not support JNI. In other words, a JNI-based native method will not execute properly with Microsoft's virtual machine even if the native method is present on the system for use by Microsoft's virtual machine.
Microsoft's Copyright Infringement
- In an earlier declaration in support of Sun's motion for preliminary injunction (5/12/98 Deutsch Copyright Decl.), I compared certain portions of source code for Sun's JDK versions 1.1 and 1.1.3 with certain portions of source code for Microsoft's SDKJ version 2.0 and Internet Explorer 4.0 for the purpose of determining the degree of similarity between the two. I have subsequently been informed that some of the source-code files in Sun's JDK are comprised, at least in part, of source code obtained from third parties. Specifically, I have been informed that some 145 of the files of Sun's JDK 1.1 source code that were included in my comparison may contain third-party source code.
- I have further been informed that if one were to exclude these files from consideration, the results of my analysis of the source code in Sun's JDK version 1.1, as reported in my declaration (5/12/98 Deutsch Copyright Decl. ¶ 27), would be modified roughly as follows:
Source files in the 1.1 java.* hierarchy
Original Results
Identical files: 266 files
Only trivial differences: 134 files
Non-trivial differences: 190 files
Total Files: 590 files
Revised Results (excluding 144 files that contain third-party code)
Identical files: 249 files
Only trivial differences: 77 files
Non-trivial differences: 120 files
Total Files: 446 files
- The results for the source files in the 1.1 Sun.* hierarchy are essentially unchanged, since this hierarchy only included a single source file that contained third-party code.
- Although I have not examined any revised figures for Sun's JDK version 1.1.3, I believe that these revised results would be similar to those for Sun's JDK version 1.1.
- The manner in which these revised figures were derived was described to me, and I am satisfied that the approach was sound and, accordingly, that the revised results are reasonably accurate.
- These revised results do not alter the conclusion that I reached in my earlier declaration (5/12/98 Deutsch Copyright Decl. ¶ 35): namely that "the only plausible explanation for this extremely high degree of similarity is that substantial portions of the Microsoft code were directly copied from Sun's source code." Similarly, based on the fact that only 145 of the 993 "java.*" and "sun.*" files that I used in my earlier analysis contain third-party code, I still believe, as reported in my earlier declaration (5/12/98 Deutsch Copyright Decl. ¶ 36), that the degree of similarity between Microsoft source code and Sun's JDK source code is also extremely high when lines of code are compared. Given that my earlier analysis found over 100,000 identical lines of code in the "java.*" 1.1 hierarchy alone, I am confident that a revised comparison would show there to be many tens of thousands of identical lines of code.