Sun Microsystems contends that by failing to implement the Java Native Interface (JNI) in its virtual machine, Microsoft prevents valid Java programs from operating correctly. In addition, Sun claims that Microsoft's inclusion of three additional compiler directives (
@SECURITY) and two additional keywords (
MULTICAST) produces an incompatible variant of the language. (For details on these issues, see Bill Day's accompanying article, "Java's creator discusses technology of Sun-Microsoft lawsuit.") In response to Sun's claims, Microsoft argues that the contract between the two parties gives it the right to make such extensions.
As a fan of Java technology, I am on the side of truth, justice, and all things beautiful -- and the truth is, the computing world has long been badly fragmented into a hodgepodge of incompatible languages, language variants, and operating systems. Of all the utility programs I have written over the years, most are unusable now because they were written in various (incompatible) languages for various (incompatible) operating systems. Anything that can reverse this trend and undo this tower of babel is a good thing. I wish the Java platform had been there at the start of my career. If it had been, I could show up on a job site now with a huge collection of tools and utilities that I had written or acquired over the years, and be 10 times as productive. So, for me, if Java versions remain compatible, that would certainly be a thing of beauty.
I favor Java's promise of cross-platform compatibility, and I contract at Sun. But that doesn't stop me from criticizing the hell out of areas of the platform that need improvement! (You can browse The JBuilder2 Bible to gauge the truth of that statement.) But, as much as I wanted the outcome to favor compatibility, I had no idea whether the licensing contract between Sun and Microsoft actually obligated Microsoft to fully embrace cross-platform compatibility as Sun contends. Truth and beauty are one thing. Justice is another. It was with that question in mind that I entered the courtroom.
Let the battle begin
I've always thought courtroom proceedings would be dry and dull affairs. But at this one, I found myself sitting on the edge of my seat. Maybe it was the high stakes: on this day, in this room, the future of an entire industry was being decided. As the proceedings unfolded, my interest was also piqued by their combative nature. In cross-examination, the lawyers looked like champions of old -- jousting for their cause.
Each side had a total of four hours in which to make their case, plus a final 45 minutes for summary argument. (Summary arguments took place behind closed doors.) As a result, the lawyers worked under intense time pressure, like grandmaster chess players struggling to make all their moves in the allotted time.
In the opinion of this observer, Sun's efforts carried the day. Whether that conclusion is shared by the judiciary remains to be seen. The remainder of this article examines the main arguments made by each side. With this information in hand, you can reach your own conclusions.
Compiler directives and keywords
One of the key issues in the case revolved around the three compiler directives (
@SECURITY) and the two additional keywords (
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.
Is Microsoft required to support JNI?
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.
At the end of the day, the contention that JNI was subsumed under the definition of the AAPI did not seem to be seriously challenged by Microsoft's attorneys. They did, however, attack that notion in a number of ways. The remainder of this article examines the validity of their arguments.
Because JNI did not exist at the time the Java licensing contract was signed, Microsoft contends that it was under no obligation to support it. Since JNI is not part of the Java Language Specification, and not part of the Java Virtual Machine Specification, Microsoft says it is not covered by the contract. On the other hand, Sun points out that Native Method Invocation (NMI) was part of the original JVM Spec, and JNI is its successor.
Which argument prevails depends on a legal interpretation of the contract. The contract between Sun and Microsoft (which you can find online; see Resources) says that Microsoft is required to pass compatibility tests for the "technology" and for its upgrades, which is defined to include the API. The AAPI, in turn, is defined as including the "OEM Java Virtual Machine Specification ... [and the] OEM Java API Specification, as modified by Sun during the term of [the] agreement." (Emphasis mine.) So, if either the AAPI or the OEM Java API Specification includes JNI, it would certainly appear that Microsoft is obligated to support JNI.
During the proceedings, Microsoft repeatedly claimed that JNI was nowhere mentioned in the contract's appended Exhibit A, which is a description of the technology and the documentation. But that exhibit does include the Java Runtime Interpreter under the description of the technology, and it includes both the OEM Java Virtual Machine Specification and the OEM Java API Specification in the list of associated documentation. And Sun contends that JNI is an enhancement of the NMI that was part of the original specification. So the odds are good that Sun is on safe ground, even if JNI is not specifically mentioned in the original version of the JVM Specification. But once again, this is the law. The outcome hangs on a definition.
Platform-independent interfaces versus platform-dependent code
Microsoft argued that the AAPI covers machine-independent interfaces. Since native code is machine-dependent (so the argument goes), JNI is not covered by the AAPI. Now, at best, this argument is spurious. (Spurious: seemingly meaningful, but in fact groundless.) At its worst, it is intentionally misleading. The fact is that JNI is a machine-independent interface. That is its beauty. Writing to this specification, a Java developer can use the Java virtual machine to link to a small machine-dependent module written by either himself or another developer.
Using JNI, it becomes possible for a company that produces a scanner (to use Gosling's example) to write a small machine-specific module for each system the scanner can be connected to. The scanner purchaser can then install the module that is appropriate for his or her platform. Any third-party Java program written for that scanner will then run, regardless of the platform it happens to be connected to. Such is the beneficial effect of standards.
To throw out a machine-independent interface (JNI) because the code it governs happens to be machine-dependent is to throw out the proverbial baby with the bath water. The code may be machine-dependent. But the interface is machine-independent. Arguments to the contrary are either based on a misunderstanding or are intentionally designed to create one.
JNI/RNI: A matter of choice
At various times during the proceedings, Microsoft's attorneys consistently made the argument that by adding compiler switches and providing RNI, Microsoft offers developers more choices, and that choice is a "good thing." Such arguments sound good on the surface. But do they really hold water? Let's examine them.
Let's start with the claim that giving developers the choice between RNI and JNI is a good thing. Now, if the Microsoft runtime included both RNI and JNI, that statement would be true. Developers could choose, for any given application, to develop for the widest possible cross-platform distribution, or for a more closely-targeted version that might deliver better performance or more functionality on a single platform. Indeed, Microsoft was explicitly granted the right to extend the VM with additional interfaces for just that reason. It's a great argument for keeping RNI. But it's no argument at all for refusing to support JNI.
By excluding JNI, Microsoft presents users with the equivalent, in the world of VCRs, of a choice between VHS and Beta Max. If distributing your work compatible with one version precludes running it in the other, you either have to deliver two versions or limit your market to those who employ one of the two machines.
But this is software, not hardware. While a video player cannot easily support two different standards, it is a straightforward matter to do so in the Java virtual machine. Then, if there were some hardware resource that existed only on the Windows platform, it would make perfect sense to use RNI. But in the case of a scanner that could easily be connected to any platform, JNI makes much more sense. The refusal to support JNI in the Microsoft VM takes away the second choice from the developer.
On a related subject, Microsoft's attorneys argued that having a mode switch on its compiler that ignores Microsoft's extra compiler directives and keywords gives developers a choice -- another "good thing." But in his testimony Gosling stressed that when Microsoft's extensions are used, turning the mode switch off either makes the compile fail or makes the runtime fail. What kind of choice is that? Sounds like the kind you get in the Army: "Do it our way, or else!" In addition, programs that use those keywords would fail using any other vendor's version of the Java compiler, which is a total defeat of the Java compatibility proposition.
While on this subject, giving developers a choice is not the same as giving consumers a choice. The reverse, in fact, is likely to be true. If Microsoft's virtual machine is present on the user's machine, and it does not support JNI, then the only programs that will run are those accessing hardware using RNI. Asking the user to install a second virtual machine in order to run programs that use JNI is like asking them to buy a Beta Max player in addition to a VHS player.
And, if only Microsoft development products produce programs that use RNI interfaces, then developers must use Microsoft development environments to use those interfaces, because only Microsoft development environments support them. That means developers must divide their efforts between two platforms, much as early video producers had to divide their efforts between VHS and Beta Max. For single-platform developers, that isn't much of an issue. But cross-platform developers need to know that JNI is standard. Then, instead of spending their time worrying about multiple versions, they can focus on delivering more functionality, and have a wider market for their efforts to boot. Both consumers and developers win, in this scenario.