Cat Fight in a Pet Store: J2EE vs. .NET
Pages: 1, 2
Counting Lines of Code
Microsoft counted the lines of code in the two applications as a rough measure of developer productivity. They argue that .NET is a more full-featured and productive environment, because the developer needs to write (and test!) less code.
Microsoft wrote a basic parsing tool that skips comments and blank lines. It looks for specific types of code in a file, such as lines of Java code in a JSP file. I used their LOC tool to reproduce their numbers. In most cases, my counts showed small, but insignificant, differences.
Microsoft skipped the HTML files and HTML tags in JSP and ASP files. Since designer tools are often used to generate HTML, counting this type of source only measures arbitrary differences in how tools output tags. These files are still hand-coded by many developers, however, and one of the advertised strengths of both ASP and JSP is the ability to streamline page development with server-side directives, custom tag libraries, JavaBeans, C# code, etc. Therefore, counting lines with tags or perhaps the number of tags seems appropriate, as long as the two visual designs are close.
Curiously, Microsoft did not apply the tool-generation argument to other parts of the implementations. For example, they point out that XML descriptor files for J2EE applications are often bigger and more numerous than configuration files for .NET deployments. But deployment tools generate most of this content (not to mention the fact that J2EE descriptor files can contain far more information than comparable .NET files). Why not exclude this code from the counts?
As usual, LOCs say little about productivity. The real questions include:
- How many developers did it take to complete each implementation?
- How many bugs remained in each final version?
- What's the total cost of ownership?
When Architectures Collide
In comparing the two code bases, Microsoft argues that the .NET architecture is superior. In fact, while the two feature sets are the same, they are really comparing implementations that satisfy two different sets of "nonfunctional" requirements.
Java Pet Store, like Java and J2EE themselves, emphasizes hardware, OS, and database portability. Performance is secondary. The .NET implementation, like .NET itself, promotes a highly integrated, single-vendor solution, where performance is emphasized. In fact, these contrasting sets of "requirements" could be implemented using either framework.
Comparison of the Middle Tier
This divide is best illustrated by the discussion of the middle tier. The .NET middle tier is quite small, about 700 LOCs in 10 files, while the Java Pet Store has about 5400 LOCs in 120 files.
Microsoft used SQL Server and exploited stored procedures for basic queries, while keeping business logic in the middle tier. This approach reduced the amount of code in the middle tier and increased performance. Also, Microsoft returned XML from the database, rather than rowsets, which streamlined working with the data in the middle tier. The .NET middle tier is small and fast, but coupled to SQL Server.
Java Pet Store demonstrates the worst-case scenario; managing persistence manually using Bean Managed Persistence (BMP) and making the application support multiple databases transparently. This results in lots of the Data Access Objects mentioned previously and avoids all vendor-specific database optimizations. Code piles up, performance is not as good, and the design is more complex. Many projects don't face these constraints. In my project that started with Java Pet Store, we simplified some aspects of the design that were overkill for our less stringent requirements.
So, Microsoft's analysis of the middle tier is an "apples and oranges" comparison. How would Java Pet Store compare if it used Container Managed Persistence (CMP) or supported only one vendor's database and exploited available optimizations? How would .NET Pet Store compare if it supported multiple databases and was database-agnostic?
Comparison of the Presentation Tier
The most informative discussion in the Microsoft analysis concerns the presentation tier. .NET has a straightforward component model that connects Web page construction, form handling, and the middle tier in intuitive ways. Component packaging is intuitive, because ASP files are bundled with the corresponding C# objects. ASP.NET provides powerful Web Forms and User Controls to accelerate client development, but at the expense of client portability. Microsoft also lavishes attention on developer tools, making it easier to construct and connect these pieces.
The organization of Servlets, JSPs, and JavaBeans more closely resembles the traditional separation between static HTML pages, which go in one place, and server-side executable code, which goes in other places. The organization is less component-oriented and intuitive, although bundling complete applications into WAR and EAR files makes deployment straightforward. Also, Java Pet Store implements design patterns for event handling and flow control, because J2EE doesn't manage these things natively. With J2EE, you get more flexibility, but more work is required and the learning curve is a bit longer.
In my project, I replaced the Pet Store presentation tier with an Apache Struts approach. Besides providing useful taglibs, Struts provides a framework for managing flow control and event handling. The Struts framework provides many of the conveniences found in ASP.NET.
So, the presentation developer can choose ASP.NET for its well-designed framework and excellent tools, but with limitations on client and server portability. Or, the developer can choose JSP and Servlets (or a Java/XML/XSLT alternative) with less tool support and a slightly longer learning curve, but with more power, flexibility, and third-party options, like Struts.
Finally, .NET has extensive caching directives that make it easier for developers to optimize page delivery. J2EE caching optimizations have largely been left up to developers and vendors. The J2EE community should provide better standard performance capabilities.
The experimental flaws of the Microsoft tests render the performance comparisons unusable. All tests must be run on the same test bed and a more suitable application must be chosen. J2EE and .NET are most appropriate for large-scale, high availability applications. The documented tests say little about how well these frameworks support those applications.
The .NET and Java Pet Stores support the same features, but they implement different "nonfunctional" requirements. The .NET version assumes a single hardware/OS/database combination and makes performance paramount. The Java version supports multiple hardware/OS/database combinations and ranks performance as less important. In fact, both frameworks can support either emphasis. Hence, comparing the two code bases is misleading.
For developers who are comfortable with limited choices, .NET is a well-designed framework with good tools. J2EE provides greater freedom, but the J2EE community can't ignore the need for tools that create powerful and efficient applications in a timely manner.
Dean Wampler is a Software Engineer with DRW Trading. He was formerly a Consultant, Trainer, and Mentor with Object Mentor, Inc.
Return to ONJava.com.