With the advent of .Net, Microsoft introduced an enterprise computing platform able to compete toe-to-toe with Sun Microsystems' J2EE (Java 2 Platform, Enterprise Edition). Microsoft's move leaves J2EE developers with two options: ignore .Net or analyze it. In this article, we choose the latter, analyzing and comparing the two technologies.

Both platforms feature innovative ideas—ideas that should cross pollinate, not stagnate on one specific platform. Furthermore, we all want technologies that add the best business value and are cutting edge, not bleeding edge! So, which language works better—.Net's C# or Java? Is .Net poised to sweep all before it or is Microsoft's mighty marketing machine simply desperate to make you think so? Well, in this two-part series we'll dive into the technologies to find out.

Read the whole "Rumble in the Jungle: J2EE Versus .Net" series:

In this article, we first examine J2EE and .Net in turn, then line the technologies up to understand how each approaches common enterprise problems. To actualize the terms and concepts introduced here, we briefly introduce our sample application: the Ice Cold Beer Boutique. In Part 2 we will focus exclusively on its background code and architecture of both J2EE and .Net implementations.

What is J2EE?

When thinking of the Java 2 Platform, Enterprise Edition, the key word is platform. Java represents more than just a programming language, as it encompasses the VM technology that lets compiled Java programs run unaltered on various machine architectures; tools to compile, analyze, debug, and deploy Java programs; and other components, such as browser plug-ins, rich media, and more. Talk about feature creep!

The three faces of Java

About two years ago, Sun reorganized the Java platform into three profiles:

  • The Java 2 Platform, Micro Edition (J2ME), for handheld and other lower-end devices
  • The Java 2 Platform, Standard Edition (J2SE), targeted at desktop machines
  • The Java 2 Platform, Enterprise Edition (J2EE), installed on servers and responsible for the heavy lifting in the Java world.

Although it's something of a simplification, you can think of J2ME as a subset of J2SE and J2EE as a superset of J2SE.

Our J2EE definition

Definition: J2EE is a Java-based technology stack, built on top of J2SE, that provides developers with the development tools and runtime capabilities necessary to build enterprise applications meeting rigorous uptime, security, scalability, and maintainability requirements.

The latest version of J2EE is 1.3. Sun uses the J2EE platform to synchronize the constituent technology specifications for specific releases. Here's a partial J2EE components list:

  • JavaServer Pages (JSPs): Generate dynamic content for Web browsers and mobile devices. JSPs resemble HTML, especially when developers use custom tag libraries to remove Java code from the JSPs themselves, making them easier to maintain.
  • Servlets: Build control and navigation logic into J2EE applications, typically following a Model-View-Controller design pattern in conjunction with JSPs.
  • Enterprise JavaBeans (EJBs): The mainstay of the J2EE platform. There are two main types of EJB: session beans that model business logic and entity beans that model persistent data. When coded correctly, EJBs provide transparent scaling, a security framework, a transaction model, and a container-managed life cycle.
  • Java Connectivity Architecture (JCA): Lets Java enterprise applications interface with existing non-Java enterprise applications like SAP. Specifically, transactions and security roles can propagate, allowing you to fully utilize legacy applications in a J2EE architecture.
  • Java Message Service (JMS): Provides asynchronous messaging capabilities to the J2EE platform. Established message-oriented middleware (MOM) vendors like IBM (MQ Series) and Tibco (Rendezvous) provide JMS faces to their products.
  • Java Management Extensions (JMX): Manages J2EE servers and applications.
  • Java Naming and Directory Interface (JNDI): A required part of the J2EE platform, JNDI provides component location transparency in a clustered J2EE environment.

Although the following components are technically part of J2SE, they prove important for J2EE applications as well:

  • Java Database Connectivity (JDBC): The real bread and butter of any enterprise application! JDBC handles all database input/output via SQL.
  • The HotSpot Virtual Machine: Can run in server mode to better profile long-running applications with stringent requirements for thread and memory management. The HotSpot VM has addressed most of the initial concerns about J2EE's performance.

Figure 1 depicts these components as a J2EE technology stack.

Figure 1. High-level overview of the J2EE technology stack. Click on thumbnail to view full-size image.

The Java community: Spirit and ethos

In addition to these technologies, the Java platform boasts another important feature: the Java developer community.

With Java, you'll find free, open source tools, such as Ant (a build tool), JUnit (a testing framework), JBoss (an application server), and NetBeans (an integrated development environment, or IDE). More exist—SourceForge lists hundreds of Java-related initiatives.

Moreover, look at the curriculum for any third-level teaching institution. In many such schools, students learn programming by studying Java. The same phenomenon pushed Unix from a 1970s research curiosity to the operating system that it is today. What's my point? The students of today are the programmers of tomorrow, and they are learning in Java and Unix.

What is .Net?

So what exactly is .Net? Unlike J2EE's specification set, .Net is a suite of shipping products (although some parts of .Net have been ratified as international standards by the European Computer Manufacturers Association (ECMA)).

According to Microsoft, ".Net is a set of Microsoft software technologies for connecting your world of information, people, systems, and devices."

Well, that clears things up! The truth is, .Net evades easy definition because it covers so many topics. Some define it as a development platform for building XML Web services, while others think it's a set of enterprise servers. Both lines of thinking prove correct, although neither tells the whole story. To get a clearer picture, let's peek at .Net's basic elements:

  • Smart client software: Software for running a variety of smart clients, from personal computers (Windows XP), to small-footprint devices like PDAs (Windows CE .Net), to set-top devices (Windows XP Embedded).
  • XML Web services: Let applications share data and consume services provided by other applications without regard to how those applications were built, what platform they run on, or what devices access them. .Net includes implementations of the latest accepted Web service standards, such as the XML Schema standard. In addition, Microsoft plans to provide many commercially available foundation services, called My Services, to serve as application building blocks. As a recent example, the MapPoint.Net Web service integrates maps and driving directions into applications. (That effort, however, has recently lost some momentum because partners have been slow to jump on board.)
  • Enterprise servers: Products that support enterprise applications by addressing different parts of the overall solution. Among the offerings in the mix are Application Center for deploying and managing Web applications, BizTalk Server for coordinating XML-based business processes across applications and organizations, and the SQL Server database application.
  • Development tools and the runtime environment: Includes Visual Studio .Net, a single integrated development environment for building .Net applications, along with the .Net Framework, which in turn includes the Common Language Runtime (CLR), ASP.Net (a new Web development environment for building Web applications and XML Web services), and an extensive set of framework class libraries.

Figure 2 below illustrates the pieces of the .Net Framework.

Figure 2. The .Net Framework. Click on thumbnail to view full-size image.

As you can see, .Net covers a lot of ground.

Note: From here on out, when we talk about .Net, we're specifically referring to .Net Framework.

Line them up

In this section, we show how J2EE and .Net solve common issues developers face when architecting a system. To help frame the discussion, we present each issue within the context of the layer where it is most relevant. The four layers we'll cover are presentation, business, data, and runtime. Additionally, Figures 3 and 4 depict the logical architecture of Part 2's sample application for J2EE and .Net, respectively.

Figure 3. Illustration of the sample application architecture under J2EE. Click on thumbnail to view full-size image.
Figure 4. Illustration of the sample application architecture under .Net. Click on thumbnail to view full-size image.

Presentation layer: HTML generation

How do the two competitors handle HTML generation?

  • J2EE: JSPs and servlets generate HTML for J2EE applications. The servlet containers include such features as session state, a security framework, and configuration. Tag libraries allow the developer to cleanly separate presentation code from control and business logic and also make the JSPs readable to HTML coders. A new initiative called JavaServer Faces aims to extend JSPs to allow developers to specify UI (user interface) components, event handling for HTML widgets, data validation, and navigation. Currently, you can handle such tasks with presentation frameworks such as Struts, Webwork, or wingS.
  • .Net: ASP.Net builds and hosts Web applications under Microsoft's Internet Information Server (IIS). ASP.Net includes the usual stuff: fault-tolerant session state, authentication and authorization, and HTML generation. With ASP.Net, developers build ASPX pages that include HTML and custom tags that map to server-side Web controls. Web controls encapsulate reusable user interface logic and provide many advanced features to ease Web programming. For example, input controls (e.g., textboxes) automatically maintain their state from one round trip to the next, so developers can access form data on the server via control properties (e.g., textbox.Text).

Business logic

Now let's see how the competing platforms handle the most commonly encountered tasks in enterprise computing: transactions, distributing remote objects, and XML Web services support.


Developers code transactions to provide systems with the so-called ACID properties: atomicity, consistency, isolation, and durability. Simply put, these properties keep your system's data coherent when things go wrong. An often used example is the ATM machine that gives you 00 in cash while simultaneously deducting the same amount from your current account. All parts of that transaction must either commit (are applied) or roll back (are not applied), and whatever happens, the system is left in a consistent state. Let's see how each platform handles transactions:

  • J2EE: Developers can either explicitly code transaction management (user defined or manual) or specify the required behavior and hand off the management to the container (automatic mode). In most cases, developers try to delegate transaction handling to the EJB container. Manually managing transactions can introduce subtle bugs into the application; in addition, the container should prove better at transaction management than you, the developer!
  • .Net: The CLR supports both manual and automatic transactions. With manual transactions, developers begin the transaction, enlist others in the transaction, commit or abort the transaction, and end the transaction. With automatic transactions, developers define an object's transactional behavior by setting a transaction attribute value on an ASP.Net page, an XML Web service method, or a class. Once an object is marked to participate in a transaction, it will automatically execute within the transaction's scope.

So which do you choose, manual or active transactions? It depends: Automatic transactions prove easier to program, but they are much more expensive in performance terms than manual transactions. Developers generally only use automatic transactions, therefore, to manage distributed transactions.

Calling remote objects

With .Net and J2EE, business logic can be encapsulated into components that may exist locally (in memory) or out of process on a remote machine. Nevertheless, both architectures follow different guidelines on how to achieve distribution:

Page 2 of 3
  • J2EE: Location transparency is a core J2EE feature. JNDI finds server-side components such as EJBs or JMS Queues, which, if running in a clustered environment, may or may not reside in the same VM. More generally, all access to an EJB must go through interfaces, which allows the application server to implement its own load balancing across multiple nodes to optimize throughput and response time. In practical terms, most application servers attempt to keep communicating EJBs in the same VM to minimize network traffic and the associated marshaling overhead. The developer can enforce in-VM execution with local interfaces.
  • .Net: With .Net remoting, developers can call remote objects distributed across application domains, processes, and machine boundaries. As you'd expect from any remoting framework, .Net remoting hides the nasty remote call details, and it formats messages and provides the underlying transport mechanisms.

    What's more interesting, however, is how you decide whether or not to use remoting. In .Net you can't automatically decide to distribute your objects as you can in J2EE, because you pay a price in network latency when you do so. You must therefore understand what you will receive in return. In the .Net world, developers employ remoting to increase security and ease maintenance, but not to improve scalability; that task is generally achieved by adding Web servers.

XML Web services

XML Web services make sense for some business problems. Let's see how both platforms support the latest technology wave in enterprise computing:

  • J2EE: By downloading and installing the Java Web Services Developer Pack from java.sun.com, you can begin creating Web services today. In the future, J2EE 1.4 will provide best-in-class Web services support. With 1.4, all EJB Web services can be consumers, and a stateless session bean can provide a Web service. Additionally, specifications such as JSRs (Java Specification Request) 67, 93, 101, and 109 enhance the Web services support in the Java platform, providing service naming, lookup, invocation, and usage functionality, respectively.
  • .Net: Microsoft placed XML Web services at .Net's core and it shows. .Net contains the latest accepted XML Web service standards (such as the XML Schema standard). Moreover, Microsoft, which groups Web services-related standards as Global XML Web Services, actively promotes other needed Web services standards.

Data access

Enterprises revolve around their data, often stored in multiple, heterogeneous data stores. Both technologies provide data access and persistence strategies, so let's dig a little deeper:

  • J2EE: Persistent data is typically modeled as entity beans. There are two main types: container-managed and bean-managed persistence (CMP and BMP, respectively). Both let developers tap into container-provided services such as transaction management, a persistence framework with intelligent database updates and caching, and a security framework, as well as leveraging the container's innate characteristics such as scalability and fault tolerance. More generally, there is a Java package to access almost any corporate data source you care to mention.
  • .Net: Developers can access a variety of data sources, including XML, through .Net's ADO.Net classes. Although ADO.Net gets its name from its predecessor, ADO (ActiveX Data Objects), ADO.Net is a rewrite rather than an upgrade. As you'd expect, ADO.Net includes data providers that let you connect to a database and execute commands. Developers can also transport data over the Web using XML Web services or across process boundaries using .Net remoting.

Platform comparison

Next, we examine both platforms to identify their common and divergent areas.

Execution engine

How do J2EE's and .Net's execution engines—the runtime architecture that compiles and executes code—compare?

  • J2EE: Java source code compiles into machine-independent byte code, which the JVM interprets at runtime. With that in mind, the particular installed JVM proves crucial to performance and scalability. Sun supplies its HotSpot VM with Java, and other JVM implementations exist, such as IBM's JVM or BEA Systems' JRockit.

    As its name suggests, HotSpot looks for repeatedly executed code sections, then intensively optimizes them. HotSpot doesn't just have great scalability and performance; it also supplies the standard configurable security model for code loading and execution.

    As a final feature, Java's JVMs leverage their host machines' strengths. For example, JVMs optimized for Solaris will take advantage of that operating system's special features, such as thread management. In this way, Java applications running on Solaris machines can scale up to more than 100 CPUs, 10,000 threads, and 100 GB of RAM per virtual machine (on the right hardware).

  • .Net: The CLR environment executes .Net's Microsoft Intermediate Language (MSIL, or just IL) code. Like the JVM, the CLR also offers support services, such as code verification, memory management via garbage collection, and code security. When you throw in an extensive set of Framework Class Libraries (FCL), you have the .Net Framework.

    The JVM and the CLR may look like identical twins, but they're more like cousins. First, Microsoft designed the CLR to support multiple languages, whereas the JVM supports only one—Java. Microsoft currently provides CLR-compliant versions of Visual Basic, C#, C++, JScript, and even Java. Other vendors are also working to support additional languages, such as COBOL, FORTRAN, and Perl.

    Second, in .Net, managed code always translates into native machine code rather than interpreted. The CLR, unlike the JVM, supports compilation from the start. Although all JVMs provide just-in-time (JIT) compilers or HotSpot today, the JVM was originally designed as an interpreter.

    Third, consider .Net's support for application domains. Application domains resemble processes; they provide the same isolation level without the overhead that comes from making cross-process calls or switching between processes, because they can run within a single process space. That ability to run multiple applications within a single process dramatically increases server scalability, something not supported by JVMs.

Cross-platform portability

Next we examine platform portability, an area where J2EE and .Net differ.

  • J2EE: J2EE offers complete cross-platform portability. If a JDK exists for your target platform, then J2EE can run on it. The ability to support Windows and mainframes and everything in between represents a big J2EE attraction.
  • .Net: The CLR includes a JIT compiler that translates IL into machine code running on target platforms. Currently, .Net only supports the Windows platform, but in theory, other platforms could have their own JIT compilers. For proof, consider the Mono project, an effort lead by a Linux company called Ximian to build an open source .Net implementation. (Note, however, that at this time Mono is not currently a commercially viable option.)

Language support

Again, language support is another major differentiator between the platforms:

  • J2EE: Tied to Java. If you want to use another language, you'll have to do it via an interface technology like the Java Native Interface (JNI) or via Web services.
  • .Net: .Net is language independent and can use any language once a mapping exists from that language to IL. At the time of this writing, several third-party vendors have produced language compilers that target the CLR; examples include NetCOBOL from Fujitsu, and Visual Perl and Visual Python from ActiveState, with others on the way. Because all .Net languages share a common type system, developers can safely pass types written in one language to code written in another. They can also use the unified Framework Class Libraries in any .Net language, saving them from having to learn how to work with many different implementations.

    This does not mean that every developer on a team should use a different language. It does mean that companies have more options, allowing them to choose the best language for the job based their developers' skills.

Standards support

Since both J2EE and .Net target the enterprise, we need to look carefully at how each platform supports the technology standards that underpin the world of e-commerce:

  • J2EE: Anyone can propose a JSR for a new platform extension, and the Java Community Process (JCP) does a great job keeping Java technology open with input from IBM, HP, BEA Systems, and many other participants. Adding to the language itself, however, proves nearly impossible. Sun is conservative about introducing changes to the Java language—a good idea, in my opinion, as it keeps the platform stable.
  • .Net: Microsoft has long been criticized for tightly controlling its technologies. However, the company took a huge step forward when it submitted C# and the CLI to ECMA for ratification. On December 13, 2001, the ECMA General Assembly ratified the C# and CLI specifications into international standards, allowing others to participate in their evolution.

Tools support

Tools support is important because it affects developer productivity:

  • J2EE: Java features a plethora of tools, which is both good and bad: the developer has a great deal of choice, but might have difficulty choosing the right tool for a given job. For example, while you can choose from numerous IDEs, which works best? It depends on the project! More generally, debugging support is good via the Java Platform Debugging Architecture (JPDA), and the arrival of Ant and JUnit has given the Java community a standard build tool and unit testing framework, respectively.
  • .Net: Microsoft's long and successful development tools history continues with Visual Studio .Net, the single IDE for building .Net applications, whether you're building Windows applications, Web applications, or XML Web services. With Visual Studio .Net, you can choose any .Net language. From the developer's viewpoint, applications are built using a single IDE. Visual Studio .Net boasts too many features to address here, but it's worth mentioning the new Server Explorer feature. With the Server Explorer, developers can access server resources (message queues, performance counters, data sources, and so on) without ever leaving Visual Studio .Net.

Vendor support

Again, like platform support, vendor support means different things in the .Net and J2EE worlds:

  • J2EE: Vendor support represents a linchpin of the J2EE world. IBM, BEA Systems, Sun Microsystems, Oracle, JBoss.org, and many others offer a wide variety of J2EE products. At present, however, open source vendors cannot become J2EE-certified—a contradiction that Sun should resolve to allow open source J2EE offerings to grow.
  • .Net: At the moment (and for the foreseeable future), .Net is a Microsoft platform. That could be either good or bad, depending on your viewpoint. On the plus side, developers need not worry about a dizzying array of choices, about inconsistencies in various vendor implementations, or about standards compliance. On the other hand, .Net locks you into Microsoft. For example, .Net runs only on Wintel machines. Depending on your organization, that lock-in may or may not be an issue.

Our thoughts

Having walked through the main points that any enterprise technology must address and evaluated J2EE and .Net for each one, what do we think about our respective causes?

Sheil on .Net versus J2EE

.Net represents a real challenge to J2EE, and, with Microsoft's integrated tools support and ASP.Net, it seems very developer friendly. However, with initiatives like the NetBeans IDE, innovative features like hot deployment of server-side components, and free tools like Ant, XDoclet, and JUnit, developers can be productive with J2EE right now.

With .Net the same age-old concerns remain: I don't want to be tied to Windows as an operating system, and I fear the associated risks in doing so. Microsoft has a poor track record in security, uptime, and stability when compared to Unix. In comparison, Java's seven years in existence, combined with Unix's decades-long evolution, make the Java/Unix combination potent where it counts: mission-critical production sites. Furthermore, I remain skeptical of Microsoft's new apparent openness toward technology standards. Has the leopard changed its spots? I don't believe it has.

Monteiro on .Net versus J2EE

So which is better? .Net or J2EE? While it's an obvious question to ask, in my view it's the wrong question. The more relevant question is: What problems are better solved with .Net? For starters, .Net shines in its strong XML Web services support.

Furthermore, Microsoft will likely continue as one of the first vendors to implement the latest Web service standards, given its leadership role in these standards' development. .Net also shines in productivity. ASP.Net's familiar event-driven programming model makes programming the Web dramatically easier than anything I've seen before.

What about security and stability? Sheil is right: Microsoft's track record in these areas is suspect, but much has changed. Last October, Microsoft announced a massive security initiative to protect customer systems from Internet-based threats. We'll see whether Microsoft's efforts suffice, but based on my conversations with Microsoft people, Microsoft appears more serious about security than ever. In the area of stability, Microsoft efforts have paid off, reaching 99.999-percent reliability with Windows 2000.


So then, should a development shop already committed to either J2EE or Microsoft-based technologies switch? And if so, what would that involve?

We say that neither side should switch! .Net represents a strong effort by Microsoft to put together a cohesive server-side platform for its clients. J2EE is already there. Who will reskill an entire development organization to switch? Do compelling reasons exist to switch from .Net to J2EE or J2EE to .Net? Absolutely not! If your development organization already excels at Java development on multiple platforms, then .Net is not for you. Likewise, if your organization has invested heavily in ASP, COM/DCOM, and Windows, then moving to J2EE makes no sense either.

In Part 2, we'll dive into the code behind a B2B business—the Ice Cold Beer Boutique (ICBB). Your homework before Part 2 is to read Sheil's "To EJB, or Not to EJB?" (JavaWorld, December 2001), in which he introduced the ICBB.

Page 3 of 3
Humphrey Sheil, a Sun-certified Java architect with Cedar Enterprise Solutions, has worked on more than 25 enterprise Java projects in Europe and the US, from initial scoping right through to going live. He also researches the parallelization of neural network algorithms for compute clusters at University College in Dublin, Ireland. Michael Monteiro is a technical specialist at Sapient, a leading business and technology consultancy that helps Global 2000 clients achieve measurable business results through the rapid application and support of advanced technology. He has more than eight years of experience delivering mission-critical applications, many of which use Microsoft technologies. As a .Net early adopter, he has spent the last year working closely with .Net and with Microsoft. In his current role, he is part of a team providing .Net architectural guidance to Sapient.

Learn more about this topic