Stop blaming Microsoft for Sun's Java woes

Stop blaming Microsoft for Sun's Java woes

By Larry Seltzer
ZDNet

June 28, 2002

Commentary--I was surprised the first time that I tried a site that required Java in Windows XP and was told that I needed to download the Java VM. The removal of JVM was Microsoft's first step in transitioning Windows users away from a built-in (or, to use a loaded word, "integrated") Java VM.

At first I thought this might be a serious problem--yet more evidence of Microsoft's "lack of support for Java." It turns out there are a few mitigating factors. First, OEMs pre-installing Windows XP or corporations doing scripted installs have the option of pre-installing the Microsoft VM. I suspect that most of them do this, and I know from personal experience that Dell does. Plus, you only have to download the Microsoft VM once and then it works. But enough was enough for Microsoft, who must have been getting enough heat from knee-jerk reactions like mine. Microsoft just announced that it will put the VM back into Windows by default (via SP1), although they will begin to remove it starting in 2004.

Microsoft's decision to move away from Java is tied to their settlement agreement with Sun, which places several restrictions on Microsoft that haven't been widely reported.

At the top of the list of restrictions: Microsoft is only allowed to ship the ancient 1.1.4 version of Java. Microsoft has taken a lot of grief for this from uninformed observers, but in fact you can blame Sun. At the time Sun sued Microsoft many years ago it stopped delivering code to Microsoft as well, which is why Microsoft's VM has never advanced beyond version 1.1.4. Microsoft actually counter-sued over Sun's refusal to deliver under the contract, but the counter-suit was thrown out along with the rest of the suit. What's more, Microsoft's removal of Java from new Windows versions starting in 2004 isn't exactly a decision it made--that, too, is mandated by the settlement agreement.

But Sun's still not happy. Now Sun argues that Microsoft should ship Sun's Virtual Machine with Windows XP. Wouldn't that be nice for Sun.

Java is a failure on the client side
Whether Java is shipped with Windows doesn't matter much for users (apart from potentially lengthening the installation of Windows), because Java on the client is so insignificant--it's a failure. A couple of Java-enabled Web sites are the only reason I have it now, but as a general desktop application platform Java's failure has been evident for a good five years or more. Do you wonder, for example, why Sun doesn't sell any desktop Java applications? Why isn't StarOffice written in Java? Probably because it would be so slow that people would only use it long enough to laugh at it.

Marc Andreessen, co-founder of Netscape and co-developer of the first graphical Web browser, summed it up in a 1998 interview, in which he joked about how a Java version of Netscape Navigator would be better because it would be slower, have fewer features, and would crash more often.

It's convenient for Sun to imply that Java is not dominant on PCs because of Microsoft's alleged misdeeds. But, in fact, Java failed in spite of Microsoft's efforts, not because of Microsoft. Microsoft's VM was the fastest available (back when Microsoft cared about it) and it was actually the most compatible with the applications that people wrote for Java. I know this because I designed and supervised the largest Java app/VM compatibility test that had been done at that point (for PC Magazine).

As far as desktop systems go, Java probably never had a chance because essentially it's an inappropriate technology for most development projects. But even if Java did have a chance, Sun's lawsuit-after-lawsuit strategy has blown it. Microsoft's VM was obviously going to be the most popular one. And by freezing Microsoft at version 1.1.4, Sun has made it difficult for anyone who wants to write an application that requires a later version of the VM. For servers, this isn't much of an issue; installing the VM is a minor problem. But having to push a giant VM to the desktop (the U.S. Windows runtime version of the latest version--1.4--is almost 10 MB) is a hassle. And, under the terms of the Sun/Microsoft settlement, Microsoft is prohibited from improving the performance of the VM.

Sun would have us all believe that Microsoft's download-on-demand is an attempt to deprive users of access to Java, but if Java is what users want, then OEMs will preload it. OEMs have this right, and when Windows XP SP1 comes along, they'll have the tools to make the Sun VM the default VM on the system. Once again, that's not good enough for Sun, which also claims, inexplicably, that download-on-demand is a violation of the settlement agreement.

Predicting the future of operating system development can be tricky, but it looks like there's one new standard feature in every new Microsoft OS: A Sun lawsuit. Sun's history in this regard is sad, and the future looks even sadder. In the end it won't make much difference to desktop users, but at least it will keep the lawyers happy.

How do you want to get JVM for XP--download it yourself, in the box with XP, from Sun, or not at all? Share your thoughts in our TalkBack forums, or drop Larry a line.

Larry has written software and computer articles since 1983. He has worked for software companies and IT departments, and has managed test labs at National Software Testing Labs, PC Week, and PC Magazine.

Lots of egregious errors in the article...

By John Le'Brecage

1) The author asserts that no applications have been written in Java?

Obviously the author isn't familiar with Forte Community edition, which is written entirely in Java. Obviously, he never downloaded Limewire (of course, he'd not admit to having a peer to peer file swapper), but that's also 100% Java. There are chat programs, browsers, clients and modeling tools all written in Java. The author doesn't want to go to a competing-with-a-C-net site like Source Forge or Freshmeat and search for java applications? None of the modern Java applications I've used with a modern VM suffer from speed problems.

Moreover he doesn't want to ask any active Java developer/consultant how many companies are running internal Java applications? or read the success reports reported monthly by Sun and the Java Lobby. Of course not, why grant the successes? Why not just lie in ignorance? There are many sites where he can find Java applications listed and Java success stories. The author has an ulterior motive, methinks.

2) The author opines: Sun should have written StarOffice in Java.

Star Office was written in C++ when the previous owners were purchased by Sun. To port StarOffice to Java would have been a massive 6 year undertaking. We'd still be waiting for OpenOffice.org 1.0 and StarOffice 6.0. We'd be in the Mozilla conundrum: late to market, with everyone asking "does it have a chance."

Sun didn't choose not to rewrite StarOffice in Java because of any inherent problem with Java like the author's belief that Java is "slow". Sun chose not to rewrite in Java, because they wanted to release a great product within a specified market window, without rewriting much code. More code was thrown away in developing OpenOffice.org than was developed! The author should have read the OpenOffice.org mailing lists before he made such a ridiculous claim about Sun's motives; sadly he could not have; otherwise, he'd not have made such a ridiculous assertion.

3) Sun is right. Microsoft was caught playing games with the contract.

The settlement agreement was that Microsoft would ship Java with the OS product, not that Microsoft would ship a means to provide user access to the product, and not that OEMs would preload Sun's product. Microsoft was obligated by the terms to take a specific action and they side-stepped that agreement. Is this any surprise? Microsoft seems congenitally unable to hew to the letter or spirit of any agreement they sign; one wonders why anyone still trusts them?

4) The author supervised a compatibility test and claims that Microsoft's VM was the "most compatible"?

Compared to what? The only comparison one can make in the Java world is to Sun's reference implementation. If Microsoft's implementation ran more applets, more often, than Sun's implementation that means that Microsoft's implementation is less compatible; not more. I don't like defacto standards, but sorry as I am to say, Sun owns the reference implementation of Java and defines what Java can run. If Microsoft's VM ran more applications than did Sun four years ago, then Microsoft was doing something fishy. One can never run more than the reference implementation unless one is engaging in embrace and extend, which (if you will all remember) was the accusation Sun made in the first contract dispute with Microsoft.

I've more mistakes to list, but surely these four will serve to show that this author isn't writing opinion based in fact, but performing a hatchet job to the disservice of Java in general. One wonders if his experience with Java extends much beyond his own desktop?