Microsoft .NET vs. J2EE:
How Do They Stack Up?

What exactly is the .NET platform [and] how does the .NET architecture measure up against J2EE?


Java runs on any platform with a Java VM. C# only runs in Windows for the foreseeable future.


.NET and J2EE offer pretty much the same laundry list of features, albeit in different ways.


By allowing cross-language component interactions, .NET is enfranchising Perl, Eiffel, Cobol, and other programmers.


.NET is a good thing for those of you committed to Microsoft architectures.


.NET will undoubtedly become the default development environment for Microsoft platforms.


However, several of the goals of the .NET platform are fairly lofty and not at all guaranteed to fly, at least not in the short term.


It would be easy to dismiss .NET as more Microsoft marketing-ware and continue on your merry way. But don't.


[Microsoft is] fighting Java and open source initiatives on their own terms, putting their own spin on "open" and attempting to directly address the needs of developers.


If you consider yourself an evangelist for Java or open source platforms, then the nature of the war is changing. Be prepared.


Microsoft has put a stake in the ground with SOAP, and they're pushing hard to put something understandable and useful in the hands of developers. J2EE proponents need to do the same with their platform.

Even if you don't write code dedicated to Microsoft platforms, you have probably heard by now about Microsoft .NET, Microsoft's latest volley in their campaign against all things non-Windows. If you've read the media spin from Microsoft, or browsed through the scant technical material available on the MSDN site, or even if you attended the Microsoft Professional Developers' Conference (where the .NET platform was officially "launched"), you're probably still left with at least two big questions:

What exactly is the .NET platform?
How does the .NET architecture measure up against J2EE?
And, if you think more long-term, you might have a third question rattling around your head:

What can we learn from the .NET architecture about pushing the envelope of enterprise software development?
The .NET framework is at a very early stage in its lifecycle, and deep details are still being eked out by the Microsoft .NET team. But we can, nevertheless, get fairly decent answers to these questions from the information that's already out there.

What is it?
Current ruminations about .NET in various forums are reminiscent of the fable of the three blind men attempting to identify an elephant: It's perceived as very different things, depending on your perspective. Some see .NET as Microsoft's next-generation Visual Studio development environment. Some see it as yet another new programming language (C#). Some see it as a new data-exchange and messaging framework, based on XML and SOAP. In reality, .NET wants to be all of these things, and a bit more.
First, let's get some concrete details. Here's one cut at an itemized list of the technical components making up the .NET platform:

C#, a "new" language for writing classes and components, that integrates elements of C, C++, and Java, and adds additional features, like metadata tags, related to component development.

A "common language runtime", which runs bytecodes in an Internal Language (IL) format. Code and objects written in one language can, ostensibly, be compiled into the IL runtime, once an IL compiler is developed for the language.

A set of base components, accessible from the common language runtime, that provide various functions (networking, containers, etc.).

ASP+, a new version of ASP that supports compilation of ASPs into the common lang