Perspective: Sun and Microsoft duke it out in court

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 (@DLL, @COM, and @SECURITY) and two additional keywords (DELEGATE and 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.

Background

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 (@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.

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.

Contractual obligation?

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.

How does Microsoft’s version of “increased choice” lead to increased competition? How does it lead to better prices and better products? It doesn’t. Going back to the scanner example: if the scanner runs on any platform, consumers are free to choose whichever machine delivers the best combination of price, performance, reliability, and functionality — just as today, they are free to choose the telephone equipment with the best combination of color, style, and functionality. Similarly, if all programs written for that scanner work on all platforms, the consumer is free to choose the program with the best combination of features at the best price.

In reality, Microsoft’s strategy limits choices. It increases the likelihood that new hardware will operate on some machines, but not on all. It increases the probability that, as now, software developers write for a single platform instead of for many. These limitations arise because developers and consumers are forced to choose between dissimilar technologies, rather than having a choice among products based on the same, standard technology.

Once again, the important point is that a valid Java program runs, period. That creates a market in which consumers’ choices of scanners and programs are not limited by the hardware platform they happen to own, or vice versa. 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.

Harm, no foul?

Microsoft brought in an economist, Professor Jerry Hausman, to talk about the tremendous cost the company would incur, should it have to retrofit its version of the VM to support JNI. It has to be granted that there is a nonzero cost. Corrective action would seem to be as simple as posting a revised version on its Web site (a process not unfamiliar to Microsoft, if the large number of downloadables at its Web site is any indication), but the cost of software upgrades includes testing and documentation, as well as programming, so it cannot be simply ignored.

Professor Hausman also claimed that cross-platform programs are not really as good as single-platform alternatives because they are slower, 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. Sometimes what appears to be a “choice” is simply a limitation, in disguise. The more compelling economic argument would seem to favor wider, less fragmented markets based on an accepted industry standard.

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, they represented a calculated attempt to confuse the issue. The inaccuracies may have been an example of courtroom legerdemain where 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 inaccurate statements must be addressed.

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 Microsoft’s RNI.” The compatibility tests make no checks for 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 user’s environment, the fact is that 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 frequently requires resolving a nightmare of conflicts between different (often incompatible) versions of hardware and software provided by multiple vendors.

A third, more subtle misunderstanding (or misrepresentation) repeated frequently in various forms was that using platform-dependent code means giving up cross-platform compatibility. The basis for that contention was mostly clearly expressed by Microsoft witness Peter Lee from Carnegie Mellon, when he stated that “A developer creating an application that uses an OS-specific feature doesn’t expect it to run on another machine…”

For the most part, Peter Lee’s statements reflected a fair and balanced perspective. But in this particular case his argument is not uniformly true. While it may be true when the developer is writing native code for a specific operating system, it certainly is not true when the developer is attempting to take advantage of a standard interface defined for a common piece of equipment. As Gosling pointed out: the concept of scanner hardware is common across all platforms. So, for example, although the interface defined for a scanner would be implemented with different code on each platform, the interface itself would be the same across all platforms. In such a case, the developer specifically expects the program to run on different machines.

The impression Microsoft’s lawyers wanted to create was that taking advantage of any platform-specific resource meant that a developer was willingly abandoning interest in cross-platform operation. But, as we’ve seen, this is not always the case. To reason by analogy, you don’t want to know what kind of telephone the other person has in order 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 with which they are implemented.

The problem with the statements examined in this section is that they could conceivably have the effect of swaying those who are unfamiliar with the issues. Fortunately, though, Judge Whyte seems to have an impressively keen grasp of the issues in this case. He also has a technical advisor to help him filter out the more egregious errors of fact.

Legal maneuvers

In an ideal world, all legal cases would be decided based on truth, justice, and the American way. But any casual observer of sporting events knows that taking advantage of the rules can give one contestant a distinct edge. Microsoft carried out two interesting maneuvers in this respect.

One interesting maneuver came about as a result of Microsoft volunteering to go first in presenting its case. The usual sequence in American jurisprudence, of course, is for the defense (in this case, Microsoft) to go last. But here the order was reversed. When presenting its case, Robert Muglia, senior VP of Microsoft’s Tools and Applications Division, was allowed to testify at length about the meaning of the contract, what his intentions were, and what Microsoft’s intentions were. Sun’s attorneys chose not to object to any of this testimony.

When it was time for Sun’s Alan Baratz to testify as to the contents of the contract, however, every attempt to express any “interpretation” of the meaning of the contract or goals for which it was instituted met with immediate objection. Although many of Microsoft’s objections were overruled, these particular objections on the basis of interpretation were sustained. From a legal perspective, it was an interesting maneuver. From a public perception perspective, though, it may ultimately backfire. It gave the impression that Sun had nothing to hide and was willing to allow everyone to have his say, while Microsoft seemed to be trying to keep as much out of the record as possible.

The second maneuver occurred late on Wednesday afternoon, when Microsoft’s attorneys announced their intention to recall Muglia to rebut the testimony given by Alan Baratz that day. Microsoft was taking advantage of having presented its case first. Sun’s attorney’s were against the recall because they would not have the opportunity to cross-examine a rebuttal witness. Showing the wisdom of Solomon, Judge Whyte decided that Microsoft’s attorneys could recall Muglia, but that Sun would get equal time to recall Baratz to rebut the rebuttal. In the end, Microsoft’s attorney’s declined to recall Muglia under these conditions.

Conclusion

Sun claims that Microsoft is required to support JNI in its VM, and that it is not allowed to add compiler directives and keywords to the language. In reply, Microsoft argues that it has acted within its contractual rights and that it offers choice to developers. I’m not a lawyer, so I’m oblivious 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 occurrence in this case — it’s probable that Sun’s request for an injunction will be granted. That would be excellent news for the Java developer community, and for consumers in general.