A J2EE versus .NET comparison

Miscellaneous Topics
#1

Really off-topic, but here it is:
http://www.objectwatch.com/FinalJ2EEandDotNet.doc

I was fairly impressed with this analysis and, well, it doesn’t make J2EE look very good I’m afraid.
It basically says .net has the advantage where costs and scalability are concerned, J2EE having the advantage of portability and choice of vendor.
IMHO, it looks like .net will probably wipe out J2EE with a few exceptions where portability is a major issue.
Which maybe also make Sun’s efforts with java as a gaming technology a good thing.
Where do you think java’s future will be? For me personally, creating indy games with java has the edge and for work I use java because we sell applications for more platforms. However, if I were to be responsible for IT in a company I would really think twice before going for a J2EE solution.

#2

Well, I haven’t read it yet, but i guess the following text on the frontpage dosen’t help the credabillity of the paper. ;D

[quote]Some of the costs for producing this paper were underwritten by Microsoft. Microsoft provided reviewers for the .NET portions of this paper, but no content or editorial control.
[/quote]

#3

“Some of the costs for producing this paper were underwritten by Microsoft. Microsoft provided reviewers for the .NET portions of this paper, but no content or editorial control. The content is entirely the responsibility of ObjectWatch and Roger Sessions
Minor editorial changes last made: 15 May 2001” ::slight_smile:

Well, I would be very supprised indead if a paper sponsored by microsoft showed that .NET wasn’t the holy grail of insert random technology here

EDIT: lol, http://www.theserverside.com/news/thread.tss?thread_id=8627
“Roger Sessions’ comparison of J2EE and .NET is fatally flawed”

Why am I not surprised :wink:

#4

I’ve been (still am) the lead design architect on 2 major client/server Java implementations and both times I’ve had to reject J2EE for these reasons:

  1. Large increased complexity overhead over some quick and dirty RMI

  2. Steep learning curve and poor tools

  3. Incredibly high rates charged by J2EE proficient programmers

  4. Incredible expense of server software (we were quoted £12k a processor for Weblogic a few years ago - we had no less than 12 processors in use for the live system - which would have meant J2EE was 50% of the entire budget. Call that a saving? Hah!)

Both times it’s worked out vastly cheaper if not necessarily quicker to just roll our own RMI based app server.

Cas :slight_smile:

#5

My goodness, that document is horrendous! Unfortunately the response AD linked to is no longer available, but I’m sure it was comprehensive and scathing.

They complain that different vendors do things differently, forcing you to just deal with one vendor. Um… Pot/kettle?

The table of equivalent technologies is filled with “not specified” on the J2EE side. Yeah, that’s because it doesn’t matter. Want a webserver? Fine, pick one. Need a firewall? Okay, which do you want to use? Really, complaining that there isn’t a single standard database, for example, is just silly.

Love the hardware tables, too. .NET is now pitched against J2EE/Unix. And blow me, UNIX boxes cost more than Wintel boxes! Another win for .NET! Except… J2EE runs on the cheaper boxes as well… doh!

[quote]Since J2EE will be layored on traditional transaction processing monitors (which the vendors have benchmarked), but will add the overhead of the Java programming language, the Java virtual machine, and the EJB (middle tier) infrastructure, a reasonable guess is that J2EE will perform at 50% of the equivalent non J2EE (e.g. Tuxedo performance). I will therefore use a 50% adjustment factor to estimate the J2EE throughput capabilities.
[/quote]
Good guess. Any evidence? No? What exactly were you paid for? Certainly not research, then…

And the final conclusion, upon which the entire J2EE vs .NET argument hinges:

[quote]The single most important differentiating characteristic between these two platforms is overall system profitability. […] For the first time, these functionalities are available at on a commodity hardware platform for a fraction of the cost of Unix based solutions.
[/quote]
Um, second time. J2EE was there first. ;D

#6

Ummm, yeah on second thought the paper is pretty bad. I already saw it’s heavily biased, but the more I read it, the more plain errors there are in there.
One thing is that it compares BEA Tuxede (not J2EE) and COM+ (not .NET) and then concludes .Net is faster than J2EE. ::slight_smile:
The more I read it, the more nonsense it seems to become.

But still, everybody I see around me seems to be going for .net these days. Maybe that’s just from my point of view but regardless of the dubious integrity of the paper, more and more people are going for .net and often for good reasons.
When I look at J2EE, the learning curve is very steep where as .net seems simpler and J2EE servers are often very expensive (although of cheap or free alternatives exist). And it’s true that J2EE programmers are expensive. Very important reasons I guess.

Erik

#7

[quote]When I look at J2EE, the learning curve is very steep where as .net seems simpler and J2EE servers are often very expensive (although of cheap or free alternatives exist).Erik
[/quote]
One answer to that steep learning curve (and associated costs) is that many server applications do not need to use J2EE in all its glory. Just a few bits (say servlets) or even just standard J2SE may suffice to get the job done.

#8

New motto: just trust the “research study” which you pay.

Well, aren’t such studies useless then? Also it would mean the one with the most money will have the most and positive … “studies”.

Sigh. Luckily you can’t buy everything.

#9

I’ll wait for Consumer Reports to compare them. ;D

#10

So is the assumption that Unix == linux or is it possible he’s really talking about a proprietary OS like IBM’s z/os or Novells equivalent mainframe systems? Because then the cost claims seem much more realistic…

#11

J2EE doesn’t have to be expensive as far as the servers go. JBoss is a great J2EE app server, and Tomcat is a very nice servlet/JSP engine. Both are open source, free, and of very high quality. We’ve been using JBoss for a couple of years, and Tomcat for many years, with great success.

#12

[quote]J2EE doesn’t have to be expensive as far as the servers go. JBoss is a great J2EE app server, and Tomcat is a very nice servlet/JSP engine. Both are open source, free, and of very high quality. We’ve been using JBoss for a couple of years, and Tomcat for many years, with great success.
[/quote]
Agreed! And you can use, for example, Eclipse as an IDE, MySQL as a database, Struts as an MVC system, Hibernate as a heirarchical object layer, Maven as a build tool etc, and never pay a penny for your software. Lots of companies do exactly this - pay nothing for the software and buy a cheap box to start with. If you become sucessful and need to expand, then you go out and buy more tin. If they wish, all they really need to worry about is development costs, and with the market flooded with Java developers you can get good ones pretty cheap, too! ;D

#13

Exactly. But stateless Session Beans are a good choice as well in my opinion – if you’re developing a fairly large project, and want to encapsulate your business logic somewhere. It doesn’t have to be complicated either. There’s a lot to be said for copy & paste… :stuck_out_tongue:

On the other hand, I’m happy to say I’ve never seen the attraction for CMP, Entity Beans, etc, etc… shudder

#14

Yeah, that’s exactly what we’re doing on my project–we use MySQL, JBoss, Tomcat, Struts, etc. It’s all great. All of those products are of the highest quality. And there is no shortage of documentation, though you do have to pay for the JBoss documentation. (Still, I think it’s like $100 a year or something like that. Totally cheap.) If a company is paying thousands of dollars for a J2EE environment, that’s their mistake; it doesn’t say anything about J2EE.

I don’t program in .NET so I’m not qualified to say anything about whether that’s a good framework or not (by most accounts I’ve heard, it is, with the only real drawback being that it’s tied to Microsoft). But I can say that one can easily get a J2EE shop going for the cost of a cheap box and a few programmers (who, admittedly, may not be so cheap–but I’d be surprised if .NET programmers were much cheaper–I could be wrong).

Willie