Fog Creek Software
Discussion Board

J2EE vs .NET

Has anyone else seen these benchmarks?  I have to say that I'm fairly surprised at the results.  The Windows/.NET solution is MUCH more scalable than the J2EE solution.  Of course, in these types of things you always have to worry about the independence of the source but this analysis appears to have been done by a Java technology consulting company.

Name Withheld
Tuesday, October 29, 2002

The thing that really struck me was not the performance numbers, but the total lines of code in each solution.

J2EE: 14,004
.NET: 2,096

That's including all source code, ASP/JSP pages, config files, etc.

An order of magnitude smaller! Even if the .NET version ran at the same speed as the Java version, it would be worth using just for the reduction in coding effort (and bug fixing - fewer lines = fewer possible bugs).

Well, that and the fact that a $48,000 app server couldn't run more than four hours without crashing. :-)

Chris Tavares
Tuesday, October 29, 2002

Smartie Rickard Öberg has prepared an assessment of the report [1] -- from my quick read it seems that a number of fundamental items (such as marking all methods on Entity Beans as requring a transaction) were kneecapped on the J2EE side.

Still, I'd have to investigate further before drawing any conclusions.


Chris Winters
Tuesday, October 29, 2002

I think the clincher is this:
EJB's do not belong in webapps except for one reason: distributed transactions, otherwise your app will be unneccessarily slow. Petstore(I believe) does not have this, so why use EJB?

As far as OOP approaches, the business logic an easily be encapsulated in beans rather than EJBs

Daniel Shchyokin
Wednesday, October 30, 2002 --

"JPetStore is a completely rewritten Pet Store application based on Sun's original J2EE Pet Store. The primary difference is that JPetStore uses a design competetive and comparable to the Microsoft .Net Pet Shop, but without its shortcomings."

By using Open Source frameworks such as Struts, the JPetStore programmer ended up within 400 lines of code of the .NET PetStore, without breaking MVC, without having to use any of the shortcuts the .NET implementation did (like storing HTML in the database)

In the programmer's own words: "JPetStore was implemented by a single developer, in his spare time, over a couple of weeks and while watching DVDs in the background"

I'll be interested to see what he does with Pet Shop 2.0.

Charles Miller
Wednesday, October 30, 2002

This assessment is based on the fact that:

- J2EE offers the opportunity to have :

* a Servlet part doing the web app
* a transactional part with EJBs doing the business work

of course, in an efficient J2EE app, why messing with entity EJBs ? Use session beans and it's the same as .NET

Also, .NET has no EJB equivalent in a .NET language. It has to link to MTS/COM (COM+) components, so there is no easy, managed way to do business components in .NET itself, let's go back to plain old COM+ programming with MTS/MSMQ where J2EE has portable EJB/JMS.

This is comparing pears and oranges, obviously a bad fit. Also, .NET uses the ADO.NET (basically going to the database and throwing SQL calls to it, something which is not OO at all, and leads to good perf for SQL code but this is achievable in J2EE too. DataSets are cool of course but this is achievable in J2EE too).
When we get to integrating diverse enterprise legacy datasources, the story will be different. What about integrating tuxedo or old mainframes ? Is there something is .NET ??? NO, not in FCL or else.

So, in a real enterprise, it is a different story than a SQL db backing a web app.

Anyway, ASP.NET is cool but do no offer tremendous value when it comes to switching to it when you have chosen Java as a strategic platform. Switching costs are way to huge. think about retraining people to C# when they were retrained to Java, rebuying the whole literature etc just for the sake of beta testing an incomplete entrerprise stack. Duh!

A lacking area in .NET (natively) is the OO mapping. They have stuff (think ObjectSpaces) but not yet good in the .NET framework itself.$

Check for a good thing on persistence - MS doesn't have it yet but this will add it to it.

The only boring thing is that Sun just is too greeding letting go of Java. Let's hope they get bought by IBM or something so that we can see it unleashed.

Philippe Back
Wednesday, October 30, 2002

And when it comes to app servers and stuff:

Tomcat or Jetty behind a load balancer with Sticky bits and
JBoss as EJB/JMS tier.

Total cost: $0 in s/w

Training cost: not that much if you have the good coders.

The problem those days is not the platforms. It's the education of the developers that is important.

Doing low perf spaghetti is possible on ANY platform.

Philippe Back
Wednesday, October 30, 2002

Maybe one big problem about J2EE architecture can be resumed like this :

- How can I provide XML based webservices (static tree view) coding 'business logic' in EJB (stratospheric OO design) while storing Data in a relational engine without building a Pudding Mapper ?

This is not about XML, which is widely adopted, this is not about Relational Databases, this is about EJB.

Has anyone here shipped in time using EJB ?

Has anyone been able to make flexible, evolutive code ?

Ralph Chaléon
Wednesday, October 30, 2002

I haven't worked with J2EE, so these opinions should be taken with a grain of salt.

.NET is pretty "easy" and may attract developers of lesser skill, leading to a rash of bad applications.  Think of all the VB6 developers who are right now being sent to 5 day training on how to be a 3-tier VB.NET developer.  It would be a shame if .NET was judged by the output of these organizations.

There are some bright SOBs doing J2EE.  Many of them can spot performance and scalability problems a mile away.

Personally, I think .NET is great and care should be taken not to compare apples to oranges when looking at the finished quality and performance of .NET apps.

Bill Carlson
Wednesday, October 30, 2002

The context of the thing seems a bit odd to me.  I mean, if a Java consulting firm did this comparison on their own and found out that the Java solution was much bigger and slower than the .NET version, why would they bother to make it public in the way that Middleware has?  Complete with an add trying to drum up consulting business (for Java?) on the very page where they require users to give contact info when they download the paper that supposedly shows Java is poor compared to .NET?  Something seems fishy. 

Now Rickard Öberg has a brief update at the bottom of his webpage at where he says:

"Several independent sources have now confirmed that The Middleware Company was indeed paid by Microsoft to conduct this report. "

Nothing wrong with that of course. 

Except that I've looked pretty carefully at the Middleware site and also at the Microsoft page linking the report, and (at least yesterday) I was unable to find any mention of this fact.  And the presentation on Middleware seems calculated to make people think it's an independent assessment by a pro-Java company.

Of course, I still don't know whether it's true.  But if it is, it seems like another example of shady marketing by MS.  If so, I hope it does come back to bite them.

Herbert Sitz
Wednesday, October 30, 2002

The problem,  Philippe, is that Sun have done a great job of propagandising the notion that UNIX == Java == J2EE.  I've seen a number of companies buy into this, and buy into the .NET vs J2EE as though they were the only options.

This is at the level of "architecture" teams and the like, so this goes up to C*O level employees.  At this point, it does become a J2EE vs .NET fight, and (much though it pains a Unix bigot like me to say it), .NET is going to be immensely superior to J2EE in many tasks.

I'm watching one client as they prepare to dismantle a small, efficient TCL + Pure Java solution to turn it into a J2EE monstoristy that will run slower, be more painful to develop for, and more costly.  Sad.

Rodger Donaldson
Wednesday, October 30, 2002

PetStoreWOJava, one of the examples included with WebObjects 5.1, has 1310 lines of Java code including comments and blank lines.  (Measured with "wc -l *.java".)

Unfortunately, the example isn't at but it is a pretty good demonstration of how WebObjects leverages MVC.

Chris Hanson
Thursday, October 31, 2002

And yet so much of the world simply does not care and uses COBOL.

old school
Thursday, October 31, 2002

C*O levels... architecture teams going stratospheric... Really, ... how to turn a good thing (Java) into a monster... (EJB2.1 CMPs). Beurk.
And then you see what MS does:

Just way ahead. They will crush J2EE if they continue that way. Really. And I am a J2EE educated person... :-(

Philippe Back
Thursday, October 31, 2002

*  Recent Topics

*  Fog Creek Home