- 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
- 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 language and the JAVA runtime environment. I have been employed by Sun Microsystems since 1984. Previous to that I was an employee of IBM research labs. I received a bachelors degree in computer science at the University of Calgary in 1977. I received a masters degree in computer science in 1982 from Carnegie-Mellon University, followed by a doctorate in 1982.
- I created the JAVA language in the summer of 1991 while working on a research project at Sun. In 1992, I designed the first JAVA virtual machine*. Since that time, I have worked continuously with others at Sun to develop the JAVA technology.
- The JAVA language and the JAVA technology were designed to minimize the extent to which software developers must create and distribute different versions of the programs they create for each of the different systems on which the programs are to be run. To accomplish this goal, the JAVA language and the JAVA technology are specifically designed to provide systems vendors the ability to implement a common software programming and runtime environment that is, to the maximum extent possible, source code and binary compatible with each of the other systems that implement the JAVA programming and runtime environment.
- I have read the Declaration of Peter Lee In Opposition to the Motion of Sun Microsystems, Inc. For Preliminary Injunction, and am familiar with the statements made therein. As Dr. Lee states, it has been very common for compiler vendors and language implementors who create compilers and runtime environments for the C or C++ languages unilaterally to extend the language and thereby introduce incompatibilities between their particular implementation of the language and those of other implementors. (Lee Decl. ¶¶ 26-32.) As Dr. Lee states, the software world he describes has created separate and incompatible compiler implementations for the Macintosh platform, Digital Equipment Corporation's Alpha processor and the Microsoft Win32 and Ole interfaces, to name only a few. (Lee Decl. ¶ 26.) Dr. Lee appears to propose that the fragmentation that plagues the C and C++ languages is both inevitable and desirable in any language, and therefore should be welcomed in the JAVA language and the JAVA runtime environment.
- Dr. Lee's proposition is antithetical to the entire reason I created the JAVA language and the reason Sun and its licensees have expended considerable resources over the past several years to develop and deploy the standardized JAVA programming and runtime environment. My objective in creating the JAVA language was to learn from the experience of C and C++ programmers for the purpose of identifying and preventing the mistakes that have led to the fragmentation and platform dependencies that plague such earlier programming and runtime environments. I found it necessary to create a new programming language to provide these benefits precisely because the existing languages, such as C and C++, had already become so fragmented and divergent in their various implementations that they could not provide the necessary uniformity to achieve source code and binary compatibility.
- The computer programming world Dr. Lee describes also bears no relevance to the rules established in Sun's Technology License and Distribution Agreement with Microsoft, which was specifically designed to constrain the ability of Microsoft, like Sun's other distributors, to fragment the JAVA programming environment. I and others at Sun were keenly aware of the risk that individual distributors would attempt to compete by building platform and operating system specific hooks and calls into their implementations of the JAVA technology. It is precisely to prevent such conduct that Sun requires each product a distributor develops to pass a comprehensive compatibility test suite designed to ensure that all such products adhere to Sun's JAVA specifications.
- Sun purposefully decided to standardize the JAVA language and the JAVA programming and runtime environment so the greatest possible level of source-code and binary compatibility could be achieved and maintained.
- The critical importance of standardization to the achievement and maintenance of the promise of the JAVA technology can be illustrated by an historical analogy. One of the essential components in the establishment of an effective railway system was the standardization of the basic parameters that allowed different trains to interoperate across different rail systems. At one time, every railway was built with custom tracks, wheels and engines. Trains from one railway therefore could not run on the tracks of another railway. It was impossible to take a trip across Europe or portions of the United States without changing railways multiple times. With the introduction and acceptance of standardized components, such as wheels, rails, switches, etc., trains could run from one railway to another. Deviation from the standards in even small ways, like changing the spacing between the tracks by less than an inch, would destroy interoperability. Moreover, it is easy to see how one railway operator could readily exclude competing railways from traversing its tracks simply by implementing a non-standard rail gauge throughout its system.
- In the computer industry, the keys to interoperability are source code and binary compatibility. Source-code compatibility is important because it enables software developers to reduce substantially the development costs associated with creating and maintaining multiple versions of source code for a given program. Binary compatibility is even more highly valued than source code compatibility. Binary compatibility enables software developers to focus their development on one version of source code, to compile, test and debug one version of binary code, and to manufacture and distribute one version of program files that can be used on every binary-compatible implementation. Binary compatibility also enables consumers to conserve resources by purchasing just one version of a program that can run on every binary compatible system, thus freeing them from dependency on a single system vendor. Finally, binary compatibility allows systems vendors to compete on the merits of their systems software, and not the relative abundance or paucity of system-dependent applications that may have been developed for their system alone.
- The fact that two implementations are source-code compatible does not mean that they will also be binary compatible. If two implementations are only source-code compatible, then a given program must be separately compiled into a new and different set of binaries for each different implementation. As illustrated in the diagram below, a software developer who wishes to write an application in the C or C++ language to run on both the Windows/X86 and the MacOS/PPC runtime environments must write separate source code for each separate environment, must separately compile that source code, and then must produce, test, debug and distribute different machine code binaries for each runtime environment.
- There are numerous technical details in the definitions of conventional programming languages, like C and C++, that make interoperability impossible. To change this, a new language, the JAVA language, had to be defined. In addition, a new runtime system (the JAVA Virtual Machine) capable of implementation and execution on widely different platforms had to be developed. As illustrated below, programs written in the JAVA language for the JAVA development and runtime environment are both source-code and binary compatible. Thus, a software developer who wishes to write an application in the JAVA language to run on both the Windows/X86 and the MacOS/PPC runtime environments must write only a single set of source code for both systems, and must compile, test, debug and distribute only a single set of binaries for the JAVA runtime environment.
- By providing a standardized programming and runtime environment for desktop and enterprise applications, one that can be implemented on a variety of otherwise incompatible operating systems and hardware platforms, the JAVA technology greatly expands the potential market for which a given application can be distributed and simultaneously reduces the cost and time required to develop applications for use with different platforms. For example, the JAVA programming and runtime environment is currently implemented on the Windows 95, NT, and 3.1 operating systems, on the Solaris, HP/UX, Linux, OS/2, VxWorks, OS9, Inferno, Chorus, AIX, MVS/MP, RiscOS, MacOS operating systems, as well as many other operating systems. It is also supported on the X86, PPC, ARM, StrongARM, Sparc, MIPS, Alpha, and microJAVA microprocessor systems.
- By rigorously ensuring that each implementation of the JAVA programming and runtime environment adheres to the same standard implementation of the JAVA language and the JAVA technology, it is possible to enable JAVA applications to be written and tested once and then deployed to each of the various operating systems and CPUs that supports a compatible implementation of the JAVA technology without significant porting work.
- There is an important source of complexity that affects some programs: JAVA is still a developing system and occasionally a developer will encounter a situation where the functionality they need from the underlying platform is not available through the JAVA VM. In such circumstances, programmers will write a portion of their application in the JAVA language, and a portion of the application in a native language supported by the host operating system, such as C or C++. This creates an application that is a hybrid of the two programming environments illustrated above. To bridge these disparate environments in a way that allows the hybrid application to run on every JAVA runtime that is implemented on the host operating system, Sun developed the JAVA Native Interface ("JNI"). JNI is a public application programming interface to the JAVA runtime interpreter that permits developers to create native code that calls JAVA code, and JAVA code that calls native code, in a way that maintains both source code and binary compatibility across all virtual machine implementations running on the same underlying platform. As illustrated below, JNI enables developers to create and distribute a single binary version of a hybrid JAVA/native application that will be capable of running without modification or re-compilation on every JAVA Compatible runtime that may be implemented on any given platform. So, for example, the same set of binaries for a JAVA/native application developed for the Windows95 platform will run on programs that utilize Netscape's Communicator, Sun's JDK, IBM's Visual Age, Symantec's Visual Café, Oracle's 8.1, and Inprise's JBuilder.
- To date, Microsoft has refused to implement JNI. In its place, Microsoft has instead implemented a native method interface that it calls RNI. In addition, Microsoft has extended the JAVA language to add a succession of unauthorized, non-standard compiler directives, including several directives that support a native method interface that Microsoft calls J/Direct. J/Direct allows developers to incorporate calls to Windows-specific native functionality in the applications they develop using Microsoft's toolkits for the JAVA programming environment. Applications that use RNI or J/Direct are not compatible with JNI and for that reason will not run on JAVA Compatible runtimes. Moreover, both RNI and J/Direct are designed in a manner that renders the applications that use them dependent on and tied to the Microsoft virtual machine. Consequently, any JAVA/native application that uses RNI or J/Direct will run only on the Microsoft virtual machine and no other JAVA runtime implemented for the Windows platform.
- As illustrated in the diagram below, the incompatibility introduced by Microsoft's refusal to implement JNI fragments the JAVA
programming environment for the Windows
platform increases the burden and cost of development, manufacture and distribution for programmers using the JAVA environment. Because Microsoft fails to implement JNI, it is not possible for any developer who wishes to create a JAVA/native code application for the Windows platform to create a single source code program, compile a single set of binaries, and distribute a single product capable of running on every JAVA runtime that may be implemented for the Windows platform. Instead, such developers must choose either to create the programs they develop for the standard JAVA programming environment, for Microsoft's non-standard implementation of the environment, or to develop, compile and distribute two separate versions of its application, one for the standard JAVA environment and one for Microsoft's non-standard environment.
- I authored the JAVA Language Specification ("JLS") along with my colleagues, Bill Joy and Guy Steele. The JLS defines the contract between implementors of the JAVA runtime environment and developers of programs in the JAVA language which allows programs to execute as intended on any virtual machine. As stated on the first page of the specification's preface, the first and most fundamental rule is that all JAVA programs must produce the same result on all machines and all implementations:
- I have read the declaration of Microsoft's expert, Michael Huhns. Dr. Huhns opines that the JLS does not prohibit the unilateral addition of new "keywords" to the JAVA language. (Huhns Decl. ¶ 17.) As a co-author of the JLS, I can say with certainty that Dr. Huhns is wrong. As Dr. Deutsch opined in his May 11, 1998 declaration, adding new keywords to the JAVA language violates the JLS, not only because the JLS defines the full set of valid keywords that may be used in JAVA language programs, but because new keywords will impermissibly alter program semantics and will cause programs not to "compute the same result on all machines and in all implementations."
- Again, the JLS makes clear on the first page of its Preface that it defines every valid language construct for use in JAVA Language Programs:
- The keywords specified in the JLS are a set of programming commands that have specific meanings in the context of programs written in the JAVA language. For example, the word "if" is a keyword that begins a section of code that will be executed only if a specified condition holds when the program is run. What "if" means in the JAVA language -- how its compiled code is interpreted by a compliant virtual machine -- is referred to as its "semantics." As Dr. Lee explains in his declaration, "‘semantics' refers to the actual meaning or behavior of a program or file format." (Lee Decl. ¶ 35) Coining non-standard keywords that have non-standard semantics will, to the extent that non-standard compilers accept and implement these new keywords, violate the axiomatic requirement that "a JAVA [source code] program should compute the same result on all machines in all implementations." JLS, Preface at xxiii.
- The JLS establishes, in Chapter 11, the "semantic constraints" of the JAVA language. (Exh. A, at 201.) As the first sentence of Chapter 11 explains, "[w]hen a JAVA program violates the semantic constraints of the JAVA Language, a JAVA Virtual Machine signals this error to the program as an exception ." (Exh. A, at 201.) Section 11.5.2.2 of the JLS provides that a compliant JAVA virtual machine will generate an error message when "an internal error or resource limitation prevents it from implementing semantics of the JAVA language." (Exh. A, at 212.) In this sense, the class files produced by the Microsoft compiler do execute correctly on other VM implementations: exceptions are raised and the program is terminated. There are two significant problems with this: this is not how the Microsoft virtual machine behaves, and it is not what Microsoft tells developers to expect. They are essentially representing to their customers that the incorrect behavior of their virtual machine is correct.
- The addition of new keywords violates the semantic constraints of the JAVA language. Consequently, when code compiled from non-standard keywords is run on a compliant virtual machine, it may cause an internal error and generate an exception, while on the Microsoft virtual machine it will do something altogether different.
- A compiler directive is a source code element that instructs the compiler to perform a specific function. Compiler directives, like keywords, define the program content, are part of the overall language processed by the compiler, and have similar rules of syntax and semantics.
- I have read the declaration of Dr. Deutsch, wherein he opines that the JAVA Language Specification prohibits the addition of new compiler directives that alter the behavior of programs that use those compiler directives. (Deutsch Decl. ¶ 50-61.) I also have read the declarations of Microsoft's experts, Drs. Huhns and Lee, who disagree with Dr. Deutsch. (Huhns Decl. ¶ 17; Lee Decl. ¶ 43.) Dr. Deutsch is correct and Microsoft's experts are incorrect.
- Adding non-standard compiler directives violates the "semantic constraints" of the JLS if the code compiled from such compiler directives alters program behavior and generates an exception when run on a compliant virtual machine.
- Moreover, adding new behavior-altering compiler directives as "tagged paragraphs" and "document comments" violates Sections 3.7 and 18.4 of the JLS. Pursuant to Sections 3.7 and 18.4, tagged paragraphs are allowed to appear in a JAVA program only in the form of document comments, and tagged paragraphs are not allowed to have any affect on the behavior of programs. (Exh. A, at 15-17, 420-21.)
- Chapter 18 of the JLS, entitled "Documentation Comments," provides that "JAVA programs can include documentation in their source code, in special documentation comments (§ 3.7)." (Exh. A, at 419.) In authoring Chapter 18, my co-authors and I intended that documentation comments, including "tagged paragraphs," could be used only to generate textual information about the program being run. We stated this provision expressly in Section 18.4: "[t]agged paragraphs identify certain information that has a routine structure, such as the intended purpose of each parameter of a method, in a form that the documentation comment processor can easily marshal into standard typographical formats for purposes of presentation and cross-reference." (Exh. A, at 420-21.) Conversely, tagged paragraphs cannot be used to insert program commands that alter the behavior of a program.
- I understand that Microsoft's new Visual J++ 6.0 ("VJ++ 6.0") and Software Development Kit for JAVA 3.0 ("SDKJ 3.0") software toolkits include the keywords "delegate" and "multicast," neither of which is included or defined in the JLS. I understand that Microsoft also has added at least three categories of new compiler directives to the implementation of the JAVA language that is incorporated into VJ++ 6.0, SDKJ 2.0 and 3.0, and Internet Explorer 4.0 (IE 4). The three new categories of compiler directives are the "@dll" directives, the "@com" directives and the "@security" directive.
- I have read Dr. Deutsch's declaration, wherein he opines that Microsoft's new keywords and compiler directives violate the JAVA Language Specification. Dr. Deutsch is absolutely correct.
- As I stated above, my co-authors and I defined in the JLS a closed set of all valid keywords. Microsoft's new "multicast" and "delegate" keywords are not "one of" that closed list, and therefore are prohibited.
- In addition, Microsoft's new keywords, "multicast" and "delegate," and its new compiler directives, "@dll," "@com" and "@security," violate the JLS because they violate the "semantic constraints" of the language by altering the behavior of programs implementing those keywords. Such programs will generate an exception when compiled on Microsoft's compiler and run on a standard JDK 1.1 virtual machine. Microsoft's expert, Dr. Huhns, agrees that Microsoft's language extensions, when compiled on Microsoft's compiler, will generate an error when executed on a standard JDK 1.1 virtual machine: "Obviously, a compiled program that seeks to use features that are not explicitly required by those two specifications will not run if those features are not present in a given implementation." (Huhns Decl. ¶ 10.) This is a clear violation of the JAVA Language Specification.
- I have read the August 14, 1998 declaration of Carla Schroer, wherein Ms. Schroer describes the Compiler Output Requirement of the JCK 1.1a Test Suite. (8/14/98 Schroer Decl. ¶ 6.) As Ms. Schroer states, the Compiler Output Requirement requires that 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 JDK 1.1. ( Id ., ¶ 10.) This JCK 1.1a Compiler Output Requirement seeks in part to police compliance with the JAVA Language Specification's "semantic constraints." It is clear from Ms. Schroer's declaration that Microsoft's keywords and compiler directives violate the semantic constraints of the JLS, because the output of Microsoft's compiler, which supports these keywords and compiler directives, does not execute as intended by the programmer when that compiled code is run on the standard virtual machine implementation contained in the Sun JDK 1.1. ( Id ., ¶¶ 6-7.)
- Finally, Microsoft's new compiler directives violate the JLS because they take the form of "tagged paragraphs" in "documentation comments." Section 18.4 of the JLS makes it clear that tagged paragraphs are not allowed to have any effect on the functional execution of programs in which they appear. Since Microsoft's new compiler directives do, in fact, affect the semantics of the programs containing these directives, they clearly violate the JLS.
- Microsoft's expert, Dr. Lee, appears to claim that Microsoft's new compiler directives do not violate the JLS because, when those compiler directives are compiled on a standard JDK 1.1 compiler, that compiler will generate output that runs on a standard JDK 1.1 virtual machine without causing an exception. (Lee Decl. ¶ 44.) While Dr. Lee is correct that a standard JDK 1.1 compiler will ignore Microsoft's new compiler directives because those directives are embedded in tagged comments, Dr. Lee is incorrect that Microsoft's compiler directives therefore do not violate the JLS. As explained above, the JLS requires that the output of Microsoft's compiler execute as intended by the programmer, without error, on a JDK 1.1 virtual machine. Neither Dr. Lee nor Microsoft's other expert, Dr. Huhns, claims that Microsoft's compiler output satisfies this requirement.
- Dr. Lee notes that Sun itself has created a compiler directive using a documentation comment tag called "@deprecated," and argues from there that the JLS must necessarily allow developers to incorporate non-specified compiler directives. (Lee Decl. ¶ 43.) Dr. Lee misses the point. Sun's "@deprecated" comment tag does not alter the behavior of the JAVA language programs in which it is used. Rather, it issues a textual warning to the programmer when the program is compiled that does not affect the behavior of the
- I have read the May 11, 1998 declaration of Dr. Deutsch in which he concludes that Microsoft's compiler directives violate Section 4.7.1 of the JAVA Virtual Machine Specification, because their compiled code generates attributes which "affect the semantics of class or interface types." (Deutsch Decl. ¶¶ 64-66.) I agree completely with Dr. Deutsch.
- I developed the initial JAVA virtual machine. It was later elaborated and its specification was authored by my colleagues, Tim Lindholm and Frank Yellin. Section 4.7.1 of the JAVA Virtual Machine Specification prohibits the implementation of a virtual machine that will interpret "new attributes" -- those not defined in the JAVA Virtual Machine Specification -- in a way that alters the behavior of a program:
- The term "semantics," as used in Section 4.7.1 of the JAVA Virtual Machine Specification, refers to the way in which a virtual machine interprets compiled code to produce program behavior. This is consistent with the standard dictionary definition of "semantics": of or pertaining to meaning, especially meaning in language (Webster's New World Dictionary). Section 4.5 of the JAVA Virtual Machine makes perfectly clear that new attributes will be considered to "affect" the "semantics," or meaning, of class or interface types if those attributes serve any purpose other than to provide additional descriptive information:
- Microsoft's expert, Dr. Lee, contends in his declaration that "semantics" does not have this plain meaning. (Lee Decl. ¶¶ 36-42.) Dr. Lee appears to contend that the "semantics of class or interface types," as discussed in Section 4.7.1 of the JAVA Virtual Machine Specification, should be regarded as not "affected" by a language extension as long as the binary compatibility requirements of Chapter 13 of the JAVA Language Specification are met:
- Dr. Lee could not be more wrong. Again, as a co-author of the JAVA Language Specification, I can say with certainty that Chapter 13 does not, and was not intended to limit the plain meaning of "semantics of class or interface types" in Section 4.7.1 of the JAVA Virtual Machine Specification. Chapter 13 of the JAVA Language Specification governs the relationship or "contract" between classes, requiring that the members and constructors of classes be accessible to other classes. It provides a necessary part of that definition, but it is not the complete definition. The core of the definition of the word "semantic" comes straight from the English language: of or relating to meaning, especially meaning in language. (Webster's New World Dictionary.)
- By contrast, Section 4.7.1 of the JAVA Virtual Machine Specification governs the compilation of class files, and the implementation of compiled code on a virtual machine. We authored Chapter 13 with the intent that adherence to its provisions would help protect binary compatibility. While Chapter 13 specifies that maintaining binary compatibility is one of the requirements with which all JAVA programs must necessarily comply, it by no means suggests that binary compatibility "overrides" or cancels other forms of compatibility specified in the JAVA Language Specification or the JAVA Virtual Machine Specification.
- If Section 4.7.1 of the JAVA Virtual Machine Specification is construed in any way in connection with the JAVA Language Specification, it should be construed in connection with Chapter 11, which, as discussed above, sets the "semantic constraints" of the JAVA language. Chapter 11 makes clear that "semantics" refers to how the JAVA language, once compiled, is interpreted by the virtual machine to produce the behavior of a program. Consistent with Chapter 11, I read Section 4.7.1 of the JAVA Virtual Machine Specification to prohibit "new attributes" generated by a virtual machine implementation to alter the behavior of a program
- In order for the JAVA technology to achieve the highest level of attainable compatibility, it is of utmost importance that any changes to the JAVA programming language be implemented uniformly with Sun as the steward. This is stated in the Preface of the JLS:
- Sun and its licensees have long recognized that, if a single licensee extended the JAVA language on its own, and altered its compiler and virtual machine implementations to accommodate those extensions, cross-platform and cross-implementation compatibility would be destroyed. We also have been well aware that, if language extensions were introduced unilaterally by Microsoft, given Microsoft's enormous installed base of desktop operating systems, the resulting incompatibility between Microsoft and the rest of Sun's licensees would threaten to create a de facto Microsoft standard.
- The danger of introducing incompatibilities in the JAVA programming language has made Sun and most of its licensees extremely reticent to make any changes to the language. This was discussed at a meeting Sun held with several licensees in February 1997. At that meeting were representatives from Borland, Metrowerks, Sybase, Symantec and Microsoft. The meeting attendees agreed unanimously that we should work together to avoid the type of fragmentation that occurred with C++. It was agreed that if unilateral language extensions were permitted, all of Sun's licensees would face the classic prisoner's dilemma. That is, each licensee would have the incentive to act first to extend the language due to the fear that, if the licensee did not act first, other licensees would extend the language in ways that favored their own technologies, thus forcing the rest of the industry to support those technologies to restore compatibility. Microsoft recognized this danger, and openly agreed that it would not, in "cowboy" fashion, make unilateral language extensions. It was also agreed that unilateral language extensions would be bad for customers, who turn to the JAVA runtime environment specifically for its compatibility across platforms and implementations.
- The importance to Sun of implementing in a standard and uniform manner any changes to the JAVA programming language is exemplified by the single change Sun introduced to the JAVA language since its inception: Inner Classes. Sun introduced Inner Classes only after soliciting input from tools vendors industry-wide, including Microsoft, to ensure that the change to the language would be as technically proficient as possible and would receive the greatest level of industry support. My colleagues and I designed Inner Classes, and I was involved in meetings of major tool vendors regarding the development of Inner Classes. Perhaps more importantly, Sun incorporated an upgrade in the JDK 1.1 technology to ensure that all licensees would be able to implement Inner Classes at the same time, on an industry-wide basis and without any detriment to platform and implementation compatibility.
- During my deposition, I was questioned by counsel for Microsoft regarding the meaning of TLDA section 2.6(b)(iv), which reads :
- I testified that the clear meaning of this paragraph to me was that, as it says expressly in the first line, it pertains to the requirements for a "new version" of a Microsoft compiler product after the release of a JDK "Significant Upgrade." I further testified that, as I read the plain language of this paragraph, it would allow Microsoft, after the release of a JDK "Significant Upgrade," to develop a compiler with one mode which that accommodates code written to the upgraded "version" of the technology, and another mode written to the previous "version" of the technology. A true and correct copy of my deposition testimony on this subject is attached hereto as Exhibit C.
- The rationale for such a provision is clear. Once an upgrade goes into effect, it is useful for a licensee to have the ability to compile pre-existing code written to the previous JDK "version" as well as the upgraded "version." A compiler vendor able to compile code written to either "version" would be assured that its compiled code would execute on an end user's runtime, whether or not that end user had implemented the upgraded runtime.
- I understand that Microsoft now contends that section 2.6(b)(iv) grants it the right, not to compile with multiple modes to accommodate multiple upgraded "versions" of the JDK technology, but instead to compile in one or more modes that are not compatible with any "version" of the technology. Aside from the fact that Microsoft's contention appears to have no basis in the language of 2.6(b)(iv) (which plainly refers to a "new version" and a "Significant Upgrade"), Microsoft's contention makes no sense in the context of the JAVA technology and its goals.
- Given the overarching goal that the JAVA technology achieve the greatest achievable level of cross-platform compatibility, Sun would never consent to a licensee using or selling a compiler with a mode that would generate output incapable of running on compatible JAVA virtual machines of the same JDK version. As I testified in my deposition, given my role as the principal developer and steward of the JAVA programming language and the JAVA technology, it is absolutely inconceivable to me that the Sun delegation negotiating the TLDA would have reached such an agreement, let alone done so without consulting me. A true and correct copy of my deposition testimony on this subject is attached hereto as Exhibit D.
- I understand that MS disagrees with the conclusion of Dr. Deutsch that the functionality achieved through Microsoft's keywords could have been achieved without new keywords, and without detriment to cross-platform compatibility. That conclusion by Dr. Deutsch is correct. Inner classes achieve all the functionality of the keywords. Sun developed them to do so. In fact, during the meetings that eventually resulted in the design of Inner Classes, one of the proposals was very similar to the multicast/delegate keywords from Microsoft. This proposal was discussed at the time and was rejected by the group because it was insufficiently powerful to solve all the problems that needed to be addressed. The person who proposed this, who worked at Borland at the time, subsequently changed employers and moved to Microsoft, where he was the originator of their multicast/delegate keywords
The JAVA Language And The JAVA Programming and Runtime Environment
/ / /
Native Methods
As seen above, Microsoft's refusal to implement JNI increases the cost of developing applications for the JAVA programming environment by forcing developers either to duplicate their development expense or to forego the opportunity to distribute their programs for use with additional JAVA implementations. Since the Windows platform accounts for more than 80% of all installed systems, Microsoft's refusal to implement JNI in Windows dramatically reduces the potential market for those developers who develop Windows-based applications using the standard JAVA environment.
The JAVA Language Specification Prohibits Adding New Keywords And Compiler Directives That Alter The Behavior Of Programs
"[A] Java program should compute the same result on all machines and in all implementations."
The complete JLS is attached hereto as Exhibit A.
"We intend that the behavior of every language construct is specified here, so that all implementations of Java will accept the same programs. …"
(Exh. A, at xxiii.) Section 3.9 of the JLS defines the valid "keywords" for the language:
Keyword: one of
|
abstract |
default |
if |
private |
throw |
|
boolean |
do |
implements |
protected |
throws |
|
break |
double |
import |
public |
transient |
|
byte |
else |
instanceof |
return |
try |
|
case |
extends |
int |
short |
void |
|
catch |
final |
interface |
static |
volatile |
|
char |
finally |
long |
super |
while |
|
class |
float |
native |
switch |
|
|
const |
for |
new |
synchronized |
|
|
continue |
goto |
package |
this |
(Exh. A, at 18.) This defined list has the dual purpose of specifying which keywords are available to programmers to use when constructing their own software, and which are not. Unilaterally adding new keywords has the necessary effect of breaking all programs that used those words as originally intended in the specification.
The JAVA Language Specification Prohibits Microsoft's Compiler Directives
Microsoft's Non-Standard Keywords And Compiler Directives Violate The JAVA Language Specification
program. Unlike Microsoft's new compiler directives, the use of the "@deprecated" comment tag will not generate an error message when a program in which it is used is run in the standard JAVA runtime environment.
Microsoft's Non-Standard Compiler Directives Violate The JAVA Virtual Machine Specification
"Compilers for Java source code are permitted to define and emit class files containing new attributes in the attributes tables of class file structures. Java Virtual Machine implementations are permitted to recognize and use new attributes found in the attributes tables of class file structures. However, all attributes not defined as part of this Java Virtual Machine specification must not affect the semantics of class or interface types. Java Virtual Machine implementations are required to silently ignore attributes they do not recognize."
A true and correct copy of the JAVA Virtual Machine Specification is attached hereto as Exhibit B.
" Attributes not defined in this specification are not allowed to affect the semantics of the class file, but only to provide additional descriptive information ."
JAVA Virtual Machine Specification at http://java.sun.com/docs/books/vmspec/html/ClassFile.doc.html, p. 18 of 43 (Exhibit B attached)
"In order to understand the meaning of ‘semantics of class or interface types' it is necessary to refer to the Java Language Specification's overriding requirements for binary compatibility. The Java Language Specification expressly indicates that compilers are not required to produce output in the exact class file format specified by the Java Virtual Machine Specification … The Java Language Specification does impose restrictions on changes to classes and interfaces, however:
‘…binaries are compiled to rely on the accessible members and constructors of other classes and interfaces. To preserve binary compatibility, a class or interface should treat these accessible members and constructors, their existence and behavior, as a contract with users of the class or interface.'
Java Language Specification ¶ 13.2. (emphasis in original). It is the sanctity of this ‘contract' about the class and interface types, and the preservation of the meaning of bytecodes, not the behavior of the program as Dr. Deutsch suggests, that is the ‘semantics of class or interface types,' which must be unaffected by new attributes."
(Lee Decl. ¶¶ 40-41.)
As Microsoft Recognized Long Ago, Unilateral Language Extensions Are Both Unauthorized And Harmful To All Of Sun's Licensees
We believe that Java is a mature language, ready for widespread use. Nevertheless, we expect some evolution of the language in the years to come. We intend to manage this evolution in a way that is completely compatible with existing applications. To do this, we intend to make relatively few new versions of the language, and to distinguish each new version with a different filename extension. Java compilers and systems will be able to support the several versions simultaneously, with complete compatibility.
(Exh. A, at xxiii.)
Microsoft Is Not Permitted To Implement An Incompatible Compiler Mode
"Subject to the satisfaction of Section 2.6(b)(iii), Licensee agrees that any new version of a Product that includes the Java Language compilation function that Licensee makes commercially available to the public after the most recent Compatibility Date shall include a mode which a Tool Customer may use to permit such a Product to pass the Java Language Test Suite that accompanied the Significant Upgrade; provided, that any version of a Product which, as of the most recent Compatibility Date, is being beta tested by third parties, shall be exempt from such requirement."
Aside From Being Unauthorized, Microsoft's Keywords Are Unnecessary
I declare under penalty of perjury under the laws of the United States of America that the foregoing is true and correct.
Executed August 21, 1998.
James A. Gosling
*As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.