Microsoft. NET and the comparison of Java EE [E]

j2ee| compare Microsoft. NET vs. Java:
How does They Stack up?

What exactly is the. NET platform [and] how does the. NET architecture measure-ee?


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


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


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


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


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


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


It would 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 Attempti Ng to directly address the needs of developers.


If you consider yourself a evangelist for Java or open source platforms, then the "nature of the" 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. Java EE proponents need to doing the same with their platform.

Even if you don't write code dedicated to Microsoft platforms, and have probably heard by now about Microsoft. NET, Micros Oft ' 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 on the MSDN site, Or even if you attended the Microsoft Professional Developers ' Conference (where the. NET platform is officially "Launche D "), 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 Java EE?
And, if you are more long-term, your might have a third question rattling around head:

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

What is it?
Current ruminations about. NET in various forums are reminiscent of the fable of the The three blind men attempting to identif Y ' elephant:it ' s perceived as very different things, depending on your perspective. Some. NET as Microsoft's next-generation Visual Studio development environment. Some the it as yet another new programming language (C #). Some the IT as a new Data-exchange and messaging framework, based on XML and SOAP. In reality,. NET wants to is all of the things, and a bit more.
A, let's get some concrete details. Here's one cut at a 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 a Internal language (IL) format. Code and objects written in one language can, ostensibly, being compiled into the IL runtime, once a IL compiler is develope D for the language.

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

Asp+, a new version of ASP this supports compilation of ASPs into the common language (and runtime therefore ASP s Cripts using any language with a IL binding).

Win forms and Web forms, new UI component frameworks accessible from Visual Studio.

ado+, a new generation of ADO data access components that use XML and SOAP for data interchange.
How do. NET and Java compare?
As you can, the. NET platform has a array of technologies under its umbrella. Microsoft is ostensibly presenting this as alternatives to other existing platforms, like Java EE and CORBA, in order to ATT Ract developers to the Windows platform. But How does the comparisons play out Item-by-item? One way to lay out the alternatives between. NET and EE is shown in the following table:

Microsoft.NET Java Key differentiators
C # programming language Java programming language C # and Java both derive from C and C + +. Most significant features (e.g., garbage collection, hierarchical namespaces) are present in both. C # borrows some of the component concepts from JavaBeans (properties/attributes, events, etc.), adds some of it own (like Metadata tags), but incorporates these features into the syntax differently.
Java runs on no platform with a Java VM. C # is runs in Windows for the foreseeable future.

C # is implicitly tied into the IL Common language runtime (in the "?? Below"), and is run as Just-in-time (JIT) compiled or compiled entirely into native code. Java code runs as Java Virtual Machine (VT) bytecodes that are either interpreted in the VM or JIT compiled, or can is COM Piled entirely into native code.

. NET Common components (aka the ". NET Framework SDK") Java core API high-level. NET components would include support for Di stributed access using XML and SOAP (ado+ below).
Active Server pages+ (asp+) Java serverpages (JSP) asp+ would use Visual Basic, C #, and possibly other languages for code s Nippets. All get compiled into native code through the common language runtime (as opposed to being interpreted each time, like ASP s). JSPs use Java code (snippets, or JavaBean references), compiled to Java bytecodes (either On-demand or Batch-compile D, depending on the JSP implementation).
IL Common Language Runtime Java Virtual Machine and CORBA IDL and ORB. NET Common Language Runtime code in allows Languages to use a shared set of components, on Windows. Underlies nearly all of the. NET Framework (common components, asp+, etc.).
Java ' s Virtual Machine spec allows Java bytecodes to run in any platform with a compliant JVM.

CORBA allows code in multiple languages to use a shared set of objects and on any platform with an ORB available. Not nearly as tightly integrated into the Java EE framework.

Win forms and Web Forms Java Swing Similar Web Components (e.g., based on JSP) isn't available in Java standard platform Me proprietary components available through Java IDEs, etc.
Win forms and Web forms RAD development supported through the MS Visual Studio ide-no other IDE support announced at Thi s writing. Swing support available in many Java IDEs and tools.

ado+ and soap-based Web Services JDBC, EJB, JMS and Java XML libraries (xml4j, JAXP) ado+ is built on the premise of XML D ATA interchange (between remote data objects and layers of multi-tier apps) on the top of HTTP (AKA, SOAP). . NET ' s Web services in the general assume SOAP messaging models. EJB, JDBC, etc. leave the data interchange protocol at the developer's discretion, and operate on top of either HTTP, rmi/ JRMP or IIOP.

The comparisons in this table is only scratch the surface. Here ' s a executive summary of. NET vs. Java:

Features:. NET and Java EE offer pretty much of the same laundry of the list of Features, albeit in different ways.

Portability:the. NET core works on Windows only but theoretically supports development in many languages (once Sub-/super Sets of these languages have been defined and IL compilers have been to created for them). Also, net ' s SOAP capabilities'll allow components on the other platforms to exchange data messages with. NET components. While a few of the "elements in. NET", such as SOAP and its discovery and lookup protocols, are provided as public Specifica tions, the core components of the framework (IL runtime Environment, asp+ Internals, Win Forms and Web forms component "Co Ntracts ", etc.) Are kept by Microsoft, and Microsoft'll is the only provider of complete. NET development and runtime. There has already been some pressure by the development of for Microsoft to open all these community, specifications this Would is counter to Microsoft ' s standard practices.


Java EE, on the "other hand," works on "any platform with a compliant Java VM and a compliant set of required platform services (EJB container, JMS service, etc., etc.). All of the specifications that define the platform are published and reviewed publicly, and numerous vendors offer Co Mpliant products and development environments. But EE is a single-language platform. Calls from/to objects in languages are possible through CORBA, but CORBA support are not a ubiquitous part of the PLA Tform.

The bigger picture
These are the last points highlight some of the key differentiators between. NET and Java, and point towards Microsoft Here. Microsoft is doing two very notable things with. Net:it are opening up a channel to developers in other programming GES, and it is opening up a channel to non-.net components by integrating XML and SOAP into their messaging scheme.
By allowing Cross-language component interactions,. NET are enfranchising Perl, Eiffel, Cobol, and other programmers by all Owing them to play in the Microsoft sandbox. Devotees of languages are particularly amenable to gestures as this, since for the most part they have felt SOMEWH At disenfranchised and marginalized in the Microsoft/sun/open Source wars. and by using XML and SOAP in their component messaging layer, Microsoft are bolstering their face and diplomatic element of openness to their platform, providing ammunition against claims of proprietary.

What ' s the correct response?
For Microsoft developers:
. NET is a good thing for those of your committed to Microsoft architectures. Asp+ is better than ASP, ado+ is better, but different, than ADO and DCOM, C # is better than. The initial version of. NET won ' t is real until sometime in 2001, so you have some time to prepare, but this'll undoubte Dly become the default development environment for Microsoft platforms. And if you ' re developing within the Microsoft development framework now, your'll undoubtedly benefit from adopting elemen TS of the. NET framework into your architectures.

However, several of the goals of the. NET platform are fairly lofty and not on all guaranteed to fly, at least Short term. The IL common language runtime, for example, has some fairly significant-hurdles to overcome before it has no real payoff For developers. Each language this wants to integrate with the component runtime has to define a subset/superset of the language that maps Cleanly into and out of the IL runtime, and has to define constructs which provide the component metadata that IL requires . Then compilers (X-to-il and il-to-x) 'll have to is developed to both compile (a) language (structures. TC.) into IL component bytecodes, and also generate language-specific interfaces to existing IL components.

There is some historical precedence here. Numerous bridges from Non-java languages to the Java VM have been developed, such as Jpython, Percobol, the Tcl/java Proje CT, and interestingly enough, Bertrand Meyer and some other Eiffel folks put together a EIFFEL-TO-JAVAVM system a few yea RS back. With the possible exception of Jpython, these tools have not been widely adopted, even within their respective language co Mmunities, even though they seem to offer a way to write code for the Java environment (albeit not the entire EE Framewo RK) using your favorite language. Why This lack of enthusiasm? I believe it ' s because people are hesitant to take on the headaches of adding yet another translation step from their deve Lopment language to the target framework. If the Java environment is the goal, people'll generally choose to learn java. I predict that the same would be true of. Net:people would generally choose to learn C # and write. NET components in Anguage.

Another Caution:beware of performance issues with. NET ' s soap-based distributed communications. SOAP essentially means XML over HTTP. HTTP is isn't a high-performance data protocol, and XML implies XML parsing layer, which implies more compute overhead. The combination of both could significantly reduce transaction rates relative to alternative messaging/communications Chan Nels. XML is a very rich, robust metalanguage for messaging, and HTTP is very portable and avoids many firewall. But If transaction rates are a priority for you, keep your options open.

For the Java and Open Source communities:

It would to dismiss. NET as more Microsoft Marketing-ware and continue on your merry way. But don ' t. . NET is a sign of a subtle but significant shift in Microsoft's strategy to evangelize their. They have been fighting alternative frameworks and platforms at the management level pretty, touting the usual Onable "Statistics" about cost of ownership and seamless integration. Now they are 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, two things this they have been faulted for not doing very. If you consider yourself a evangelist for Java or open source platforms, then the "nature of the" is changing. Be prepared.

Also, Microsoft ' IL runtime has at least one notable, if improbable, goal:eliminate the programming language as a Barrie R to entry to the framework. Java eliminates the platform barrier (within limits, of Course:you can ' t make up to missing hardware resources with soft Ware, for example), but in order to work in Java EE, you have to work in. . NET wants to we use the language of your choice to build. NET applications. This is admirable, though there are a big questions as to whether and while the IL approach in. NET would actually become dly useful (above). Regardless, this is points to a weakness in the single-language Java EE approach. The importance of this weakness are questionable, but it exists nonetheless, and deserves some consideration by the Java Co Mmunity. If This is really desired by developers, then maybe the efforts into Java bytecode generators for Non-java languages be organized and consolidated.

Focusing on EE, there are a few issues that should is addressed immediately in order to bolster the advantages of that P Latform compared to what. NET are shooting for. The XML support needs to is integrated seamlessly into the framework. I ' m not talking about bolting a XML Sax/dom parser to the set of standard services, or extending the "use of" XML in config uration files. XML messaging and manipulation need to is there, ready to use. Admittedly, you can use XML payloads in the top of JMS messaging, but the platform doesn ' t facilitate '. The XML space is a cluttered mess of standards, de facto standards, APIs and DTDs, which are to being expected when you ' re DEA Ling with a meta-language.

But 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. Java EE proponents need to doing the same with their platform. One possibility that comes to mind be to add a XML messaging "provider" layer on top of JMS, along the lines of the Patte RN followed by Java naming and Directory Interface, or JNDI, with LDAP, NIS, COS naming, etc. This in combination with a standard Soap/biztalk provider, a EbXML provider, etc. would is an impressive statement.


Clarifications and corrections
Since the publication of this article in August and readers have responded with their own thoughts about. Net vs. j2e E. (The Reader responses.) Jim Farley, the author of this article, has sifted through those, as as is as email he's comments, and received the F Ollowing clarifications and corrections.
Clarifications
The description of C # ' s compilation features vs. those of Java seems to have confused some. To put it another way:c# code always runs natively. Java code typically runs as interpreted bytecodes, and can run natively. C # is either compiled entirely to native code, or it are compiled into the common language runtime bytecodes and then just- In-time compiled to native code during execution. Java code, on the other hand, typically runs as runtime-interpreted bytecodes (from which its cross-platform abilities SPR ing), and can also run in a just-in-time the compiled context. Some Java Native-code compilers also exist (Jove, Bullettrain, JET, etc.).
As a side note, Microsoft claims this default interpretive mode of Java is a liability, in which bytecodes designed for A virtual machine does not lend themselves as a. Native optimization. I Haven ' t seen any hard the data to prove or disprove that claim, either generally (bytecodes vs. native-compiled languages) O R specifically (Java vs. C #).

Several readers, in response to the "call to" include XML support in Java, mentioned the fact that Java EE 1.3 (currently in PU Blic draft) requires that any J2ee-compliant product must include Java XML SAX and DOM parsers. But This is just "bolting a XML sax/dom parser" to Java EE, as I mentioned. I am calling for it to is taken a step farther, to incorporate XML support directly in the Java EE support APIs. Ideally, j2ee-based components and services would have XML support (for messaging, interface description exports, etc.) au Tomatically built-in, to some extent.


Corrections
I State in the article that C # "borrows some of the component concepts from JavaBeans." This statement can ' t is proven, and, as several readers pointed out, it's more likely that Microsoft based the component F Unctionality of C # more on their own COM and VB models, with influences from the other pre-existing component.