Shadow initiatives: .Net and Java

It first really hit me when I read an article on what, at the time, was called ASP+, now dubbed ASP.Net. This is, of course, the next-generation .Net-associated version of Microsoft's Active Server Pages. A lot of what was cool about it reminded me of Sun's Java Server Pages but with some enhancements that reflected Microsoft's development philosophy. When I started looking around I noticed that much of .Net was obviously, at least partly in reaction to Java initiatives.

Of course, there's nothing surprising about this, and I suppose nothing embarrassing either. The roles have been reversed in the past; JSP itself builds on prior art in the dynamic Web page space, the most significant product there being ASP (it was also one of the earliest ones). J2EE is heavily (ahem!) "influenced" by Microsoft Transaction Server, the current descendents of which are in COM+. And probably everything both companies have ever done was done years ago by IBM, but that's just a truism of the computing industry.

The similarities between Java and .Net initiatives are usually obvious. For example, in ASP.Net and JSP the pages are pseudo-compiled so that they run faster. If you look for the differences, you can often see typical Microsoft patterns, especially for their development tools. (Some of you are already laughing about "typical Microsoft patterns," but one of the reasons they do these things is that they are very successful with them. Developers like their products.)

One pattern is that Microsoft gives developers a lot of freedom, even freedom to do dangerous things. For example, in C# Microsoft includes ways around the safety and security features of the language in case developers want or need to use them. James Gosling, inventor of Java, recently ridiculed these back-doors, such as the ability to create actual pointers, but the jury's still out on them. If you're going to force people to write all new code, as Sun does with Java, then making it difficult to do things like interact with non-Java code is tolerable. Microsoft places a high premium on preserving existing code and allowing new programs to interact with it, so these back-doors are necessary to their vision for .Net.

Another pattern is multi-language support. Long before .Net came around, Microsoft criticized Java for forcing developers to do everything in one language. In fact, some of the changes Microsoft put into their Java VM--for which Sun sued them--were to support interaction with other languages. When it came to building their own VM, Microsoft designed it to support multiple source-level languages. Once again, the jury's still out on this because some of the things they try to do are difficult and involve trade-offs. For example, different languages have different physical formats for data types. If different languages are going to have to interoperate with the same data, they may have to violate their own internal standards. Consider strings in COBOL, which are fixed length by long-established standard, and strings in C which are variable length. If compiler vendors follow standards, code may not interoperate; if they make special .Net data types, programmers will have to modify code. But at least you can write COBOL on .Net and port existing programs, as opposed to retraining all your COBOL programmers in Java and rewriting all your code.

But obviously the whole idea of using a VM for the new .Net platform indicates that Microsoft decided that Sun was right about at least one aspect of it. There being nothing new under the Sun (ha ha), the virtual machine is a pretty old idea, and it's not like Sun invented anything fundamental in this regard. My first job out of college was writing code to run on the UCSD p-System, a virtual machine that ran my binary programs on any number of very different hardware and software platforms. But this was back in the days when processors ran at several megahertz and high-end systems had perhaps 1MB of RAM, so VM programs were unbearably slow. Nowadays a VM, such as Java's or .Net's, is something users will tolerate.

Beyond the basic systems architecture there are numerous initiatives within Java and .Net that mimic each other. Consider Java 2 Micro Edition and Microsoft .Net Compact Framework, both of which are designed to squeeze the platforms into small devices like cell phones. Both Microsoft's Active Data Objects (ADO.Net in the new platform) and Sun's Java Data Objects (JDO) provide easy access to databases.

Over time, it was inevitable that Sun would start to develop initiatives influenced by .Net, much as Scott McNealy would prefer to ridicule it as ".NOT". Clearly Microsoft was on to something with the whole XML-based Web services thing, and Sun's customers must have been asking for something like it, hence Sun ONE (Open Net Environment). It's amazing how Sun's Web services marketing gobbledygook sounds a lot like Microsoft's Web services marketing gobbledygook.

Read the news superficially and you'd get the impression that these two companies don't respect each other, but I think it's more complicated than that. I expect .Net and Java to "influence" each other heavily over time, as each company sees the other implement something worth ripping off. That's competition for you.

What's your take on .Net and Java? E-mail Larry or post your thoughts in our Talkback forum below.