In the first week of December, when evidentiary hearings were scheduled in the Sun-Microsoft case, Baltimore was hit by its largest snowstorm in three years. Much of the city was shut down. But Judge Motz kept his courtroom open, asking the dozens of attorneys involved in the case to show up through the snow; according to one witness in the trial, the judge himself slept in his chambers one night to make sure he got to court in the morning. The 42-page ruling (PDF here) Motz issued a couple of weeks later speaks to that determination; it is, if there can be such a thing, a judicial tour de force. In a plain, first-person narrative, Motz goes through the sordid history of the battle between Sun and Microsoft over Java, grappling with each side's arguments and explaining rather elegantly why requiring Sun's Java in copies of Windows would be best for all parties involved.

Judges presiding over litigation involving complex technology often seem adrift in the jargon. Motz, though, gives the impression of someone well-schooled in Java and .Net, and his support of Sun's position -- he almost completely sides with Sun -- and rejection of Microsoft's is grounded in tech and business realities. His theory, in brief, is this: The sorry state of Java on desktop computers -- the "fragmented" market, in which most computers have old versions of the Java software, and some people have a bastardized, Microsoft-friendly version, causing developers to sour on the platform -- is probably the result of Microsoft's "anticompetitive conduct." Although the issue will be fully argued in an eventual trial, Microsoft, he says, appears to have used its Windows monopoly to destroy "Sun's channels of distribution" for Java; and now, having done that, Microsoft wants to introduce into this rigged marketplace its alternative to Java.

The only way to set the market right, Motz says, is to attempt to reverse Microsoft's actions. Requiring Microsoft to offer Sun's Java in Windows, he wrote, "is designed to prevent Microsoft from obtaining future advantage from its past wrongs and to correct the distortion in the marketplace that its violations of the antitrust laws have caused."

Who caused Java to fail on the Windows desktop? Of all the questions argued in the various trials involving Microsoft, this one is perhaps the most difficult to answer. Certainly, as the evidence shows, the people at Microsoft were intent on seeing Java fail. But many say that just because Java did fall flat on its face, and just because Microsoft pushed it a little here and there, one can't conclude that Microsoft deserves all the blame. Java, people point out, had a slow graphical interface and generally poor performance otherwise -- couldn't it have tripped up all on its own?

Greg DeMichillie, who used to work at Microsoft on its C#, C++ and Java programming applications, and who's now an analyst at the firm Directions on Microsoft, is one such skeptic. "There's a lot of people who say that Microsoft wanted to kill Java" because it was "write-once, run-anywhere," he says. "But really, people at Microsoft just thought that was a ridiculous notion, and they didn't pay any attention to it. They said, 'For technological reasons, we don't think write-once will work."

DeMichillie concedes that Microsoft added many "extensions" to Java in its programming environment that, when used in a program, would cause the program to run only on Windows. But he says that those extensions were put in to improve Java on Windows, not to pollute Java. "What they liked about Java was that it was easier to write applications in it. They liked it better as a programming language. And so they said, 'Let's make Java a good way to write a Windows application.' And of all the stuff that's been said of what Microsoft did to Java, it's good to point out that they did make a better version of Java. Microsoft does have some really sharp people, and they know Windows inside and out, and so if anyone were to make Java faster on Windows they were the ones to do it."

He also says that Microsoft did not do any of this quietly; Microsoft warned developers that its tools could result in Windows-only applications. "I remember they were very upfront about it," DeMichillie says. "When they came out with their Java tools that had Windows-specific features, they were very clear, in their communication with developers, that it was Windows-specific. The notion that Microsoft was trying to make people think they were building cross-platform applications when they weren't, that's not true."

Perhaps DeMichillie is right, but his version is not supported by the facts. In his opinion, Motz cites numerous internal Microsoft documents -- such as the Bosworth memo and Gates' reaction to it -- that suggest a company-wide effort to dupe developers into thinking they were building cross-platform programs that in truth ran only on Windows.

For example, Thomas Reardon, a Microsoft executive in charge of Internet operations, wrote in November 1996 that "We should just quietly grow [Microsoft's Java tools'] share and assume that people will take more advantage of our classes without ever realizing they are building win32-only java apps." Significantly, too, the findings of fact from the government's antitrust trial -- 412 very damaging statements about company behavior that may, in time, turn out to be the most important legacy of the never-ending federal case -- state that the company didn't start warning developers about compatibility issues with Microsoft's Java tools until 1998, when it was ordered to do so by a court. (Because those facts were set down during previous litigation, Microsoft has little room to re-argue them in this case; Motz presumed them to be true. In the past, though, Microsoft has argued that what executives write in e-mail doesn't necessarily reflect company policy.)

So the question lingers -- was Java on the desktop always broken, or did Microsoft break it? In the end, we may never get an answer; but as Sun will point out, it's telling that Java did well in all markets where Microsoft didn't have a monopoly. Why did that happen? Eight years after the introduction of Java, it seems clear: The language was successful because, some initial problems notwithstanding, it provided a much needed, innovative programming interface at just the right time.

Recent Stories