J2EE vs .Net : the never ending debate

In this cutting edge technology era, we are all looking for technologies, which can add the best business value. When Microsoft introduced .Net, which is an enterprise computing system and can compete with Sun Microsystems' J2EE (Java 2 platform, Enterprise Edition), the J2EE developers and Java lovers had two options, i.e., ignore .Net or analyze it. We'd rather take the route of analyzing the .Net platform.

Before going to any further technical analysis, let's take a look on what is .Net. Two to two and half years before; there was confusion even in the IT industry, what exactly .Net is! Is it a new version of Windows or a new language called C# (pronounced as C sharp)? The answer is simple; it is an enterprise computing system which consists of .Net Framework which is the virtual machine and class library that replaces COM and Web Services which is driven by XML. Web service is not a revolution in distributed computing. It is instead a natural evolution of XML application from structured representation of information to structured representation of inter-application messaging. The other elements of .Net are Smart Client Software, Enterprise Servers and the Development Tools and Runtime Environment.

Now it's time to see, what is J2EE? It's a Java based technology stack that provides developers with the development tools and runtime capabilities necessary to build necessary applications meeting rigorous uptime, security, scalability, and maintainability requirements. The J2EE components are Java Server Pages (JSP), Servlets, Enterprise JavaBeans (EJB), Java Connectivity Architecture (JCA), Java Message Service (JMS), Java Management Extensions (JMX) and Java Naming and Directory Interface (JNDI). The other two technically important components are Java Database Connectivity (JDBC) and the HotSpot Virtual Machine.

Now let's see the J2EE and Microsoft .Net approach to develop enterprise applications and web services. Like any other enterprise application, web services also have to be reliable, highly available, fault-tolerant, and scaleable and must perform at acceptable levels. The shared vision between both J2EE and .NET is that there is an incredible amount of 'plumbing' that goes into building web services, such as XML interoperability, load-balancing, and transactions. Rather than writing all that plumbing, developers can write an application that runs within a container that provides those tricky services. It's important to understand that J2EE is a standard, not a product. What's exiting about Java is that it enables developers to write their code once, and deploy their code onto any platform. The process is like this:

• Developers write source code in Java.


• The Java code is compiled into bytecode, which is cross-platform intermediary; halfway between source code and machine language.


• When the code is ready to run, the Java Runtime Environment (JRE) interprets this bytecode and executes it in runtime.

J2EE has architecture for building server-side deployments in the Java programming language. It is used to build traditional web sites, software components, or packaged applications. It has recently been extended to include support for building XML-based web services as well. These web services can interoperate with other web services that may or may not have been written to the J2EE standard.

Now let's see the functionalities of Microsoft.NET. Firstly, it is largely a rewrite of Windows DNA, which was Microsoft's previous platform for developing enterprise applications. Windows DNA includes many time-tested technologies that are in production today, including Microsoft Transaction Server (MTS) and COM+, Microsoft Message Queue (MSMQ), and the Microsoft SQL Server database. The new .NET Framework replaces most of these technologies, and includes a web services layer as well as improved language support. In other words, Microsoft.Net is a generation ahead than its previous Windows DNA platform.

Microsoft.NET offers language-independence and language-interoperability. This is one of the most intriguing and fundamental aspects of the .NET platform. A single .NET component can be written, for example, partially in VB.NET and C#.

Let's look at the process of .Net. First, source code is translated into Microsoft Intermediate Language (MSIL). This MSIL code is language-neutral, and is similar to Java bytecode. The MSIL code then needs to be interpreted and translated into an executable. The .NET Framework includes the Common Language Runtime (CLR), similar to the Java Runtime Environment (JRE), which achieves this goal. The CLR is Microsoft's intermediary between .NET developers' source code and the underlying hardware, and all .NET code ultimately runs within the CLR.

This CLR provides many great features which were not available in earlier versions of Windows DNA, such as automatic garbage collection, exception handling, cross-language inheritance, debugging, and execution of different versions of the same .NET component.

After knowing these technical features offered by J2EE and Microsoft.Net, let's see what developer community is saying. Just what they're going to like, depends on personal taste. Owing to its roots in the well established Java development language, J2EE is perceived by many to be more mature-and, therefore, a safer bet-than its rival. Java, after all, has become ubiquitous within university programming courses, something that should guarantee a large and available pool of Java-skilled developers for the long term.

But Microsoft is miles ahead in case of providing single-vendor solution. Where in case of J2EE, there are almost 30 plus Middleware vendors (like IBM's Websphere, BEA's Weblogic, etc.), Microsoft is giving everything packaged which is ready to develop applications.

Once it was easy to reduce the J2EE versus .NET question to bring in platform level - choose Windows and you're tied to .NET, pick J2EE if you're using UNIX - recent changes in the industry mean that's no longer a guarantee.

Finally, doing the job is exactly what these platforms are all about. Corporate customers now have two extremely robust, well-received application platforms on which to base their future Web-based businesses. This is not a very clear answer to the question "which platform is better" - but it may help many managers sleep well knowing they no longer have to sell their souls when making the choice.