Columns

The more things change ...

• By Tony Baer
• June 1, 2001

Remember Sun's and Microsoft's rivalry over Java, which spawned a lawsuit that produced a settlement that benefited no one? From the millions invested in legal fees, one would think that both sides were fighting over product lines with real revenues. In truth, Sun makes relatively little, if anything, from Java, while Microsoft won't make anything directly from its Java alternatives. Meeting halfway wouldn't have dented either company's bottom line, and would have made life simpler for developers.

But this was a battle of philosophy. It was Sun's insistence on protecting the Java Virtual Machine (JVM) to maintain the "write once, run anywhere" ideal vs. Microsoft's philosophy of going native—with the platform, that is.

The real battle was over the hearts and minds of next-generation developers. Java filled a huge hole, providing some of the ease of use associated with Visual Basic, in an environment that was more powerful and disciplined. Although Java never achieved VB's market penetration, its impact on Microsoft was stronger than the company would admit.

Microsoft needed an alternative, and it benefited developers. A year ago, Microsoft unveiled C#, its "better Java than Java." Like Java, it is a tamer version of C++, but there are clear differences. In place of a virtual machine, C# lets developers take direct advantage of Windows and platform APIs. But it doesn't eliminate the need to port to other platforms.

Depending on your perspective, C#'s approach to security is either more flexible or more dangerous than Java's. With C#, you can configure security measures using a combination of rules and auto-sensing, which detects when something bad is happening. By comparison, Java's sandbox was initially designed as absolute. And for memory management, in place of Java's Chinese Wall, Microsoft lets you check off a dialog box that asks if you want to create some "unsafe" C++-style memory pointers.

One advantage C# gained by coming out after Java is supporting XML from the outset. It offers XML-based self-documentation and it can map XML meta data directly to C# classes. But Sun has had to retrofit XML support to Java after the fact.

In some cases C# gets carried away: it supports versioning down to the class level, which Java fans might see as too much of a good thing.

Aside from their C++ roots, it seems that Microsoft's and Sun's approaches to advanced development languages differ like night and day. But don't be too quick to judge. Yes, Microsoft has trashed the idea of virtual machines and byte code as inefficient. However, C#—and other .NET languages—will no longer compile directly like Microsoft languages used to. As part of the .NET environment, C# will translate to "Intermediate Language," which will do the dirty work. Microsoft claims there's virtually no performance penalty there. Maybe that's because Microsoft just adopted Just-in-Time compiler technologies similar to those Sun has used to speed up Java.

Sun also bit the bullet when it freed real-time embedded Java from the protected sandbox and performing garbage collection. The dilemma was that, to get decent performance, Java programs required memory footprints that were up to four times larger than C or C++, which was an obstacle to working with small embedded devices. Garbage collection also got in the way.

So we have two visions of managed, object-oriented languages that provide developers a healthy choice. In some ways, the visions are complementary: Microsoft's Common Language Runtime feature, supported by C#, that allows any language to compile similarly on the .NET platform vs. Sun's Java language that will run on any platform. Beneath the covers, however, things ain't as different as they seem.