Columns

Analyst's Soapbox: A nasty wake-up call for J2EE

• By Gary Barnett
• December 31, 2002

A tainted benchmark doesn't prove a thing, but the Java community would be foolish to avoid the warning it represents.

At the end of October, a ''damning'' benchmark demonstrated that Microsoft's .NET is twice as fast as the faster of two ''leading'' commercial J2EE app servers when running a benchmark based on a new implementation of Sun's Pet Store app (see http://www.middleware-company.com/j2eedotnetbench). The benchmark was produced by The Middleware Company, long an advocate of Java and J2EE.

More bad news for Java junkies: The .NET solution required 2,096 lines of code vs. 14,004 lines of Java code. And, under the price performance analysis, .NET is shown to cost 2.5 times less. So it's three early goals for Microsoft. But then things go wrong; it seems Microsoft provided The Middleware Company with a lot of help in developing the .NET solution, while the two other vendors (presumably BEA and IBM) didn't participate.

Next comes an own goal by The Middleware Company: A quick analysis of the Java app that is meant to be an optimized version of Sun's Pet Store app reveals some architectural choices that aren't optimal. Not an advertisement for a company that sells J2EE expertise.

The benchmark is tainted; it's not a fair comparison. But in following the avalanche of feedback from the Java community, I've been struck by the number of Java lobbyists who will not or cannot accept that Microsoft can offer a real alternative to J2EE. Next, I've been alarmed by the speed with which many Java developers seem to rush to blame 'EJB' for the poor performance and complexity of the app. Let's face it: EJB is a rather important part of J2EE, isn't it?

The worst thing the Java community could possibly do is to try to ignore or avoid this report.

Naturally, the Java disciples are out in force; crying foul, making excuses and accusing The Middleware Company of ''selling its soul to the devil.'' And in symmetry, the Microsoft camp can be expected to make its own ludicrous claims.

Tragically, Java supporters are trying to deny that the benchmarking exercise happened. This is stupid for two reasons: First, .NET represents an alternative to J2EE, and for the majority of apps it is viable. Second, J2EE is too complex and cumbersome -- it must improve.

The Java community cannot argue that Java has ''other virtues'' by using the mantra of ''performance comes second to reliability, maintainability and portability.'' This is based on three fallacies.

First, Java apps are not more intrinsically reliable. Reliability is as much a function of the developers who write the code as the environment within which that code runs.

Second, Java apps are not intrinsically more maintainable -- it's developers that make apps easy or hard to maintain.

And finally, Java's alleged portability is often grossly overstated as a virtue. Even only moderately complex apps require porting effort to move them between app servers, even at times between different versions of the same app server.

That the same technology can be used across many platforms is a huge advantage, but only if you really do need to develop new functionality across those platforms.

This report is of great importance to the Java community and, if rational heads prevail, it will bring great benefits to Java technology and the people who use it.

How do I think the community should respond? Read the report!

Java supporters should take the medicine and forge ahead to address the issues it raises. It is an act of denial to pretend that .NET doesn't pose an alternative to J2EE.

J2EE must be simpler, and it must run faster. If it cannot meet these challenges, it will wither on the vine and a great chance to change IT will be squandered.

Vendors (and the whole Java community) should take up the challenge and optimize Java code for their platforms. The benchmark needs this to be credible. As for potential adopters of .NET or J2EE: Be aware that you have a choice. Few of you truly have scalability requirements that come close to ruling .NET out, and claims about the technical 'superiority' of one technology over the other are spurious. Look at what you need and at your skills base, and make a decision based on what is best for you.