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, .) In response to Sun's claims, Microsoft argues that the contract between the two parties gives it the right to make such extensions.
At the outset, I attended the Sun versus Microsoft hearing with essentially no bias. As a fan of the Java technology, I am on the side of truth, justice, and all things beautiful. The truth is, the computing world has been badly fragmented into a hodgepodge of incompatible languages, language variants, and operating systems. Anything that can reverse this trend and undo this Tower of Babel situation must be a good thing. Of all the utility programs I have written over the years, most are unusable now because they were written in various (and incompatible) languages for various (and incompatible) operating systems. I wish Java had been there at the start of my career. If it had been, I would 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 if Java versions remained compatible, that would certainly be a thing of beauty.
Because I favor the Java proposition, I contract at Sun. But that doesn't stop me from criticizing the hell out of things that need improvement. You can browse The JBuilder 2 Bible (now available from IDG Books) to gauge the truth of that statement. But, much as I wanted the outcome to favor compatibility, I had no idea whether the contract was written well enough to do so. 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 that courtroom proceedings would be dry and dull affairs. But at this one, I found myself gravitating to the edge of my seat a lot. 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.
The proceedings involved the typical direct examination, whereby witnesses are led by their own attorneys, and cross-examination by the opposing attorneys. Each side had a total of four hours in which to make their case, plus a final 45 minutes for summary argument. The resultant time pressure and necessity for managing the clock made the lawyers look like grandmaster chess players, banging the clock after each move, in attempt to make all their moves in the allotted time.
Arching over everything was the matter of strategy. Sun's attorneys seemed content to bring out the facts and let them speak for themselves. Microsoft's attorneys engaged in a variety of legal maneuvers and a variety of arguments, as the defense is entitled to do. In all respects, Sun's counsel appeared superlative. In the opinion of this observer, their 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 so you can reach your own conclusions.
Compiler directives and keywords
The case for the compiler directives and keywords seems clear. The Java Language Specification lists all of the keywords that are part of the language, along with a couple that are reserved for future use. Under direct examination by Sun attorney James Batchelder, James Gosling, Sun VP and Fellow, pointed out that the compiler directives and keywords that Microsoft has added simply are not part of the language. Furthermore, Alan Baratz, President of Sun's Java Software Division, pointed out in his testimony that nowhere in the contract is Microsoft granted any rights to 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 Runtime Native Interface (RNI) defined by Microsoft, but does not support the Java Native Interface (JNI) defined by Sun, any program utilitizing 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, September 9. 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 that, the definition of AAPI had been expanded to ensure future compatibility with any all interfaces defined by Sun -- documents that are the result of 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 that Sun publishes on its Web site. (Those specifications are sometimes authored by Sun and sometimes by other parties, so the process truly is an industry-wide collaborative effort.)
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 attacked it in a number of ways, however. The remainder of this article examines the validity of those 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 it is not part of the Java Language Specfication, and not part of the Java virtual machine (JVM) Specification, it does not exist as a contractual entity. On the other hand, the Remote Method Invocation was part of the original JVM specification, and JNI is its successor.
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 Applet Application Programming Interface (AAPI). 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 added). 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. On the other hand, 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 RMI 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 specifications versus platform dependencies
Microsoft argued that the Applet Application Programming Interfaces cover machine-independent interfaces. Since native code is machine-dependent (so the argument went), 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 either by himself or others.
Using JNI, it becomes possible for a company that produces a scanner, for 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 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 JNI because the code it connects to is 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
Microsoft's attorneys consistently made the argument that Microsoft was providing the developer with more choices, and that choice is a "good thing". That argument sounds good on the surface. But does it really hold water? Let's examine it.
Before Judge Whyte, the Microsoft side claimed that having the choice between RNI and JNI was a good thing. Now, if the Microsoft runtime included both RNI and JNI, that statement would be true. The developer 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 "Hob's Choice". ("You're danged if you do, and danged if you don't.") It's like having a choice between VHS and Beta Max. You can choose to distribute your video in one version, but doing so precludes the other. The history of the market shows that a new market never really takes off until some cohesive standard is accepted. While the VHS and Beta Max wars were going on, the video market never really took off. Right now, the digital video disk market is only starting to emerge after a long struggle with competing standards. Sun is attempting to preserve the only standard that has heretofore existed in the world of computing. That standard creates market opportunities that cannot exist otherwise.
On a related subject, Microsoft's attorneys argued that having a mode switch on their compiler gave developers a choice, which was another "good thing". On the other hand, Gosling pointed out 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? You get those kind of choices in the Army: "You can do it my way, or else!"
The bottom line is that giving a developer a choice is not the same as giving consumers the most choices. The reverse is likely to be true, in fact. If the Microsoft's VM is present on the user's machine, and it does not support JNI, then only programs that access hardware using RNI will run. Asking the user to install a second virtual machine to use 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 are forced to use Microsoft development environments to access hardware resources through the virtual machines that are widely distributed on Microsoft platforms.
How does any of this increase competition? How does it lead to better prices and better products? It can't. Once again, the point is that a valid Java program runs, period. Here again, the Microsoft products create situations where a "valid" program runs in one context, but not in any other. That is not only fundamentally contrary to the spirit of Java, it is fundamentally against the spirit of competition. (If we both make VHS VCRs, we are competing. If you make VHS and I make Beta Max, we are in different, though related, businesses.)
Harm, no foul?
Microsoft brought in an economist, Professor Jerry Hausman, to talk about the tremendous cost that would Microsoft would incur, should it have to retrofit its existing version to support JNI. This fact has to be granted. There is always a substantial cost for such undertakings. The point is not irrelevant, either. If the judge decides that the case is "too close to call", then the request for an injunction will be denied as result of the substantial burden it would impose on Microsoft. On the other hand, if the judge decides that Microsoft brought this all on its own head, then it won't matter what the cost is -- Microsoft shouldn't have done it in the first place, so it is up to Microsoft to live with the costs of its actions. The interesting result of their argument is that, if the judge decides to grant the injunction, it is a clear indication that in his opinion Sun's arguments have substantial merit, and are likely to prevail.
However, Professor Hausman also claimed that cross-platform programs are not really good because they are so slow compared to single-platform alternatives, and that Microsoft's virtual machine is "pro-consumer" because it offers "more choice". As we have seen, though, the concept of "choice" is a double-edged sword that must be used judiciously. We have seen how a hardware vendor, with a very small investment, can create drivers for multiple platforms, and that 3rd party application developers (or the vendors themselves) can then write machine-independent programs that provide non-trivial functionality regardless of platform. By developing functionality instead of worry about platform compatibility issues, developers can be more effective and deliver better products. All of this undoubtedly works to the benefit of the consumer. It is difficult to see how any effective argument can be made to the contrary.
Misunderstanding and misdirection
Several statements were made by Microsoft's attorneys or their witnesses that seemed to reflect a basic misunderstanding of the issues. Or else they were a calculated attempt to confuse the issue. One hopes the former, but fears that latter. It may have been an example of "courtroom legerdemain" where, like a magician, the attorney seeks to misdirect and mislead the audience (in this case, the judge). One hopes, instead, that the opinions were the result of simple misunderstandings based on a zealous desire to serve the client. But in either case, the misunderstandings need to be addressed, lest they interfere with rational analysis.
For example, in reading the contract, one Microsoft attorney argued that the clause regarding compatibility testing meant that "If Microsoft adds an API, Sun can test for it." That is simply not the case, of course. If Microsoft adds an API, Sun can and will ignore it. As Alan Baratz stated, "we have no problem with RNI". The point of compatibility testing is to ensure that Sun's interfaces are honored.
Another statement that went into the record was, "If I'm an application developer, I control as much of my environment as I can." Well, assuming here that we are talking about the end user's environment, the fact is the we do what we can when we can, but the amount of control we really have in today's world is staggeringly little. Ask any systems administrator in a company that has individual workstations. Their work is a nightmare of resolving conflicts between incompatible versions.
A third, more subtle misunderstanding (or misrepresentation) that was repeated frequently in various forms was that using platform-dependent code means giving up cross-platform compatibility. For example, Microsoft witness Peter Lee from Carnegie Melon stated that "A developer creating an application that uses an OS-specific feature doesn't expect it to run on another machine." In other words, once having decided to take advantage of a platform-specific resource, the developer has expressly abandoned all interest in cross-platform operation.
In the most narrow of cases, where a singular capability of the platform is being utilized, there is some truth to that statement. But in the general case, it is simply not true. James Gosling put things most clearly when he pointed out the concept of scanner hardware was common across all platforms. As we saw in our scanner example, JNI provides a platform-independent path to drivers that are, of necessity, platform-specific. In such a case, the developer is specifically expects the program to run on different machines. To reason by analogy: the interface is like a telephone. You don't want to know what kind of telephone the other person has in order to choose the telephone you use to make a call -- you just want to know that when you call, the other party will answer. That interoperability exists because the telephones all respect a common interface, regardless of the equipment they are implemented with.
The problem with such statements is that they could conceivably have the effect of swaying a judge who was unfamiliar with the issues. Fortunately, though, Judge Whyte seems to have an above-average grasp of the issues. He also has a technical advisor to help him filter out the more egregious nonsense.
The final attack against Sun's position came in the form of legal maneuvering. In an ideal world all cases would be decided by "truth, justice, and the American way". But any casual observer of sporting events knows that an advantage accrues to those who know where the rules can be bent, without actually breaking them. Microsoft carried out two interesting maneuvers, in this respect.
One interesting maneuver came about as a result of Microsoft volunteering to prevent its case first. The usual sequence in American jurisprudence, of course, is for the defense to go last. But in this case the order was reversed. This ordering allowed for some unusual "sandbagging". When presenting its case, Microsoft's Robert Muglia was allowed to testify at length about the meaning of the contract, what his intentions were, and what Microsoft's intentions were. All of this testimony was given without objection.
But when it was time for Sun's Alan Baratz to testify as to the contents of the contract, every attempt to express any "interpretation" of the meaning of the contract or goals for which it was instituted met with immediate objection. These objections were sustained, because they were allowable -- if somewhat unfair, since they were not extending the same courtesy that they had been given. From a legal perspective, it was an interesting maneuver. From a public perception perspective, though, it may ultimately backfire. It gave the impression that the lack of substantial evidence made such maneuvers necessary. And Sun's attorney's are now forewarned. Come the final trial, one can expect the gloves to be off.
The second maneuver occurred when Microsoft's attorneys announced their intention to recall Robert Muglia to "rebut" the testimony given by Alan Baratz. Once again, this sequence was made possible by their decision to present their case first. Sun's attorney's were against the recall because they would not have the opportunity to cross-examine. Showing the wisdom of Solomon, Judge Whyte decided that Microsoft's attorneys could recall Muglia if they wished, but then Sun would have equal time to recall Alan Baratz to rebut the rebuttal! Interestingly, Microsoft's attorney's declined to recall Muglia under these circumstances.
I'm not a lawyer, so I can be oblivous to some of the nuances of the legalistic phrasing that shows up in contracts. If logic and rationality prevail, however -- never a foregone conclusion, but a likely occurence in this case -- then it is probable that Sun's request for an injuction will be granted. That would be excellent news for the Java developer community, and for consumers in general.
Learn more about this topic
- Sun legal documents
- Request for injunction (and arguments justifying it)
- Original Technology Licensing and Distribution Agreement (TLDA)
Note: When you see the word redacted in these documents, it means that material has been removed in order to protect trade secrets. It's like "retracted", except the text isn't actually taken back -- it's simply not present in the version you are reading. Interestingly, the space it occupied is still there, so you can gauge how much of the document was redacted.