Page 2 of 6
One of the key issues in the case revolved around the three compiler directives (@DLL, @COM, and @SECURITY) and the two additional keywords (DELEGATE and MULTICAST) supported by Microsoft's version of the compiler. Programs using these extensions to the Java language only run with Microsoft's
versions of the compiler and runtime interpreter. However, under direct examination by Sun attorney James Batchelder, Sun
VP and Fellow James Gosling pointed out that the compiler directives and keywords added by Microsoft simply are not part of
the language. Furthermore, Sun Java Software Division President Alan Baratz emphasized in his testimony that nowhere in the
contract is Microsoft granted any rights to extend the Java language. The contract covers the Java runtimes and compiler --
not the language itself.
The bottom line is that a valid Java program must compile and run, period. That is the proposition that Sun is going to great lengths to defend. The Microsoft version provides for programs that are "valid" in one context but not in another -- and that is contrary to the very purpose and rationale of Java itself.
Because Microsoft's virtual machine supports the Raw Native Interface (RNI) defined by Microsoft, but does not support the Java Native Interface (JNI) defined by Sun, any program utilizing native code that runs in one environment will not run in the other. This situation creates a serious breach in the Java compatibility story. All other implementations of the Java virtual machine support JNI, including versions created by Oracle, IBM, Symantec, and Inprise, as well as those created by Sun. Microsoft is the one outstanding exception. The question is, is Microsoft required to support JNI under the terms of its contract?
The crux of the matter was summarized by Alan Baratz, in testimony given under the direct examination of lead attorney Lloyd Day on Wednesday afternoon. Stepping through a series of definitions in the contract, Baratz stated that the definition of the Applet Application Programming Interface (AAPI) had been defined in the contract to include all interfaces defined for the virtual machine, including the native method interfaces defined by Sun that allow Java programs to access native code.
Baratz did not deny that Microsoft had the contractual right to define its own interfaces, for example, in the form of the Windows-specific RNI. That right was explicitly granted so that Microsoft could produce a highly efficient version of the Java runtime that could be accessed by Microsoft operating systems and utility programs. But, because the contract had been enlarged to allow these extensions, the definition of AAPI had been expanded to ensure future compatibility with the interfaces defined by Sun -- specifications that result from the open-specification process that addresses concerns from anyone and everyone in the industry who cares enough to voice an opinion on the preliminary versions published by Sun on its Web site.