Gosling testifies on technical merits of Sun’s claim
September 9, 1998 — Sun and Microsoft appeared in U.S. District Court in San Jose, CA in this week to present evidence and testimony supporting each of their arguments in the Sun vs. Microsoft case, which centers around Microsoft’s implementation of Java technology. By everyone’s reckoning, this is an important case, one which will have far-reaching effects on Sun and Microsoft as well as their partners, ISVs, and even end users. Please refer to the Resources for more information on the case.
For all the rhetoric, at its core this is a potentially straightforward contract law case. It has been complicated for the court, however, by the technical nature of the material in the contracts.
It isn’t often that Perry Mason meets Java virtual machines and native method interfaces, but that’s exactly what transpired at this week’s hearings. James Gosling, the acknowledged creator of Java, spent more than two hours on the witness stand on September 9, giving an in-depth Java tutorial and explaining the technical issues critical to Sun’s case.
The foundation for Sun’s complaint
Sun Microsystems’s legal basis for its case against Microsoft revolves around a few key points. They are:
-
That Java’s central promise, the most important feature in Sun’s and many other developers’ minds, is its cross-platform portability. Sun spent a lot of effort building this up; Microsoft’s lawyers tried to tear it down at every turn.
-
Sun held that Microsoft’s implementation of Java violates this promise, and supposedly the letter of the law as specified in the Technology License and Distribution Agreement (TLDA), by breaking compatibility and portability. Sun asked that Microsoft be required to fix its Java products such that its code remains compatible with other runtimes (i.e., passes the Java Compatibility Kit tests).
- Furthermore, Sun held that Microsoft willfully chose to violate the contract. If true, this would allow Sun to claim damages done to its business and could be used to demonstrate anticompetitive business practices, not a boon for Microsoft as it currently faces antitrust actions from the US Department of Justice.
In order to lay the foundation for Sun’s arguments, Sun’s lawyers spent a great deal of time questioning Gosling on the technical details of Java, Java runtimes, and native method interfaces that allow Java applications to be cross-platform portable. What follows is a description of the technical material covered in Gosling’s testimony, and of Microsoft’s response. (You can review a written declaration from Gosling on the subject via the URLs in the resources at the end of this article.)
Are native methods portable?
Gosling spent some time explaining that the entire design of Java centers fundamentally around portability. This is true even with the native method interface, the Java Native Interface (JNI) beginning with Java 1.1 and beyond. (Interestingly, Gosling admitted that the Java 1.0 Native Method Interface (NMI) was really just a quick fix to help make Java available as soon as possible. Though the developers in the crowd already knew this, Microsoft’s lawyers harped on this point later in trying to show that even Sun’s own implementations of the JDK 1.0 and 1.1 were incompatible at the native code level because of Sun’s changes to the interface.)
Gosling illustrated how JNI allowed for portability of code written to interface with the Java virtual machine (JVM), even if it could not allow for complete portability of native code interfacing with the underlying OS libraries. As he described it, this was the absolute highest level of portability possible, given the differences between various OS windowing systems and utility libraries. Again, Microsoft harped on the point that even JNI did not allow complete portability of all code.
After demonstrating the ways in which JNI code is as portable as possible, Gosling proceeded to illustrate how and why Microsoft’s Raw Native Interface (RNI) results in nonportable code. He also mentioned that it is not only technically feasible for Microsoft’s JVM to support both RNI and JNI, but that Microsoft already does in fact support multiple APIs in many of its products. Specific examples included RNI, COM, and JDirect.
Gosling also explained how JNI would be loaded only on demand, as Java applications needed to use the interface, so that no additional memory bloat would be incurred. Judge Ronald Whyte ask several questions on this point, eventually satisfying himself as to demand paging and how it affects the loading of libraries in modern operating systems.
Violations of the Java Language and Java Virtual Machine Specifications
Gosling then testified concerning the nature of Java keywords and of Microsoft’s creation of two new keywords and three compiler directives.
The two keywords Microsoft added to its Java language implementation are:
multicastdelegate
The three compiler directives under discussion were:
@dll@com@security
Gosling and Sun argued that these Microsoft-specific keywords and directives result in incompatible Java bytecodes, which in turn generate exceptions on any non-Microsoft JVM. Gosling held that this violates the Java Language Specification (JLS) requirement that a compliant JVM must compute the same result for the same Java code as the reference JVM, Sun’s JVM. Gosling also testified that the addition of the compiler directives violates the JVM Specification (see resources for online versions of both specifications) by resulting in previously undefined attributes which affect the semantics of the containing class files.
Microsoft held that these extensions to the language are allowable and that a particular portion of the JLS that lists approved keywords starting with “keywords, one of” does not in fact preclude additional keywords. The interpretation of “one of” seemed to quite clearly preclude additional keywords according to Gosling, despite Microsoft suggestions to the contrary.
Microsoft also stated that “competent developers” should be able to tell the difference between Microsoft-specific extensions and standard language features, and choose accordingly in their code. Gosling pointed out that developers do not always have the luxury of choosing the libraries they must work with, and that if a required library did in fact use Microsoft extensions, the developer would be locked in to the Microsoft JVM and runtime. Gosling stated that “Normally, a developer doesn’t just wake up and say ‘I want to write a Java program.’” This drew a round of laughter and agreeable glances from developers in the viewing area.
Gosling discusses intent
Having attempted to demonstrate both the importance of Java’s cross-platform nature and how Microsoft has violated the JLS and JVM Specs, and in so doing, the very cross-platform nature of the language, Sun’s lawyers finally turned to demonstrating Microsoft’s malevolent intent.
Gosling recalled being present at a meeting in early 1997 at which Sun, Microsoft, and several other Java licensees and vendors all unanimously agreed that unilateral extensions to Java language or virtual machine technologies by any one vendor were highly undesirable. Gosling stated that one Microsoft representative at that meeting even went so far as to state that Microsoft would never be so “cowboy” as to build unilateral Java extensions itself. But that is exactly what Microsoft then proceeded to do with its keyword and directive extensions, Gosling asserted.
Conclusions
Gosling’s technical testimony was followed by more contract- and intent-oriented testimony by Sun Java Software Division President Alan Baratz. The hearings finished with a closed session of Sun and Microsoft arguments, at which point Judge Whyte adjourned the hearing to weigh his decision on whether or not to grant the injunction.
Judge Whyte is expected to rule on the injunction within the next few weeks.
