Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Another J2EE vs .NET Performance Comparison

michael posted more than 11 years ago | from the mine-is-bigger dept.

Programming 533

Starting yesterday, we received a bunch of story submissions about a performance comparison between J2EE and .Net. It didn't seem all that exciting, and we sort of ignored the story. But as usual, it appears that some people take issue with the methodology and conclusions.

Sorry! There are no comments related to the filter you selected.

Important Notice (-1)

Sexual Asspussy (453406) | more than 11 years ago | (#4565568)

ffffff pppppp nnn nn iiii ggggg zzzzzz
ff pp pp nnnn nn ii gg zz
fffff pppppp nn nnnn ii gg gggg zz
ff pp nn nnn ii gg gg zz
ff pp nn nnn iiii ggggg zzzzzz

gr33tz: dk, gnr/tlg, klarck, ras, rws, xdf

shoutz: moms, pops, Allah, the CLIT, MC Rob Base & DJ E-Z Rock

death by a THOUSAND nigs: spork_testicle, Editors, you.

how are you gentlemen?

Slashdot Has Been Own3d (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4565886)

The lameness filter has been de-lamed, and Slashdot has been re-llama-ed by Monsier AssPussy.

Excellent work.

Some of us (3, Insightful)

Anonymous Coward | more than 11 years ago | (#4565586)

Some of us are not in a position to dictate policy. Love Linux or not, some of us will have to use .Net or look for another job.

Not a good option during these bad economic times.

Re:The sad thing is... (3, Insightful)

GreyWolf3000 (468618) | more than 11 years ago | (#4565660)

It's not about loving Linux. It's about loving Freedom (TM). And that means not having a centralized conduit for information exchange. It means my computer being mine.

On a side note, I wish the 'net were never called the 'Information Superhighway.' That single analogous dubbing has spurred the acceptance of rhetoric in Congress that allows all sorts of regulation.

Re:Some of us (1)

wmspringer (569211) | more than 11 years ago | (#4565745)

I suppose there's always the possibility of some people actually liking .Net ;-)

I haven't used it myself, but I caught part of a presentation Microsoft was giving about it (free pizza! ;-)) and it looked like it had its uses.

Although, I shouldn't talk...I like doing my programming in linux or java under a simple text editor :-)

Re:Some of us (0)

Anonymous Coward | more than 11 years ago | (#4565767)

I like doing my programming in linux

you mean C, Perl, Python, Ruby, PHP

Linux is just the kernel!

Re:Some of us (0)

Anonymous Coward | more than 11 years ago | (#4565844)

you mean GNU/C, GNU/Perl, GNU/Ruby, GNU/PHP

haha hopefully all the morons who try to make this crappy joke will see this post and realize it's already been made


Re:Some of us (0, Flamebait)

Neumann (240442) | more than 11 years ago | (#4565794)

This isnt about who dictates policy. This is about a company lie^H^H^H misrepresenting (either intentionally or unintentionally) the capabilities of a product. In other industries this is called "false advertising" and is against the law, but the tech industry doesnt seem to have to follow rules that other industries do.

Re:Some of us (2, Insightful)

Anonymous Coward | more than 11 years ago | (#4565833)


Ever wonder why MS is putting .NET ads on Slashdot?

Well, posts like these are the other shoe dropping.

Rest assured, many many many companies are evaluating MS technologies vs. OSS technologies for a number of good reasons; Security, reliability, scaleability, non lock-in, no subscription plans, etc.

For example, see the story posted on Slashdot just yesterday [] where the US DoD is advocating the use of FOSS (Free & Open Source Software). Read the report and the recommendations.

What's remarkable about this report is that it's written by Mitre and DISA (Defense Information Systems Administration), both very conservative groups when it comes to new technologies.

I'm posting anonymously because my employer has close ties with MS and after what happened to Bruce Perens for speaking his mind...

Compare OpenTheo to the NetSuckas (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#4565603)

This mail archive is the complete (as far as I know) communication between myself and the NetBSD core between December 15 (when they removed all my NetBSD access) and the day OpenBSD was formed. It
actually goes a little further beyond that time, and includes mail from a few other people involved in the negotiations.

This archive makes it clear that I tried everything I could to avoid having to form a seperate project, but that the NetBSD core holds the complete responsibility for the need and creation of OpenBSD, another splinter group.

After my access was revokes, I struggled for 7 months to get access to the CVS tree back. I was told to agree to things others did not have
to, to wait for an agreement document -- it's all in the archive. It was suggested that I merge my 19,000 lines of diffs by mailing them to
an individual who would merge them. The entire affair was ridiculous.

Those people are
Charles Hannum
Chris Demetriou
JT Conklin
Paul Kranenburg
Adam Glass
There are newer NetBSD core members, but they have done nothing to change the situation.

Performance isn't most important (4, Interesting)

Faggot (614416) | more than 11 years ago | (#4565613)

The beast most of us have sitting on our desk these days is so fast as to make language performance not such an issue. What should be focused on to support the future of computing is a well-typed, well-structured language to allow programmers to think at a higher level of abstraction than previously. That's why I love Mac's standardization of Objective C so much -- it allows high-level control of programs. Performance only matters if it sucks.

Re:Performance isn't most important (2, Insightful)

kpansky (577361) | more than 11 years ago | (#4565671)

Actually languages still continue to matter a great deal even now. While computers are getting ever faster, do you really want to offset speed gains by using languages that are inefficient for many tasks?

Don't get me wrong. I love high-level languages. Python is one of my favorite languages. However, I would not ever consider doing driver implementation or operating system work in python. Something must be said for low-level languages and their ability to relate directly to the hardware they are running on.

Re:Performance isn't most important (2, Insightful)

NitsujTPU (19263) | more than 11 years ago | (#4565710)


Performance is an issue in enterprise applications. The difference between buying 50 servers and 100 servers matters.

Re:Performance isn't most important (5, Insightful)

Twirlip of the Mists (615030) | more than 11 years ago | (#4565715)

(Given your user name and other info, I expected a troll. Turns out you said something reasonable. Weird.)

What you say is true on the desktop, but this comparison is between two server technologies. Desktops are fast enough these days for what we want to do with them, but servers are still often heavily overloaded. If you build a big n-tier web application, chances are it's for a commercial purpose, right? So your goal in life is to get more and more people to use that web application, so you can make more money and whatever whatever. If your application can't scale as far as you need it to, it's bad, bad. So performance is very important in situations where the size of the application user base needs to scale dependably.

"Twirlip of the Mists" (0)

Anonymous Coward | more than 11 years ago | (#4565894)

Given your user name and other info, I expected a troll.

It sure is a good thing that no one takes you for an idiot because of your unbelieveably stupid user name.

Mods, please mod this racist jerk DOWN. Mr. Judging-by-appearances here doesn't deserve the karma he's getting.

Re:Performance isn't most important (2, Funny)

PhysicsScholar (617526) | more than 11 years ago | (#4565765)

But what do I know. I'm just looking for anonymous gay sex.

Wait, let me get this straight (no pun intended) -- you're a gay man who says "performance" isn't important.

Christ, next thing you know you'll be saying that size doesn't matter!

Re:Performance isn't most important (0, Troll)

MagPulse (316) | more than 11 years ago | (#4565789)

Only the fastest Java desktop applications are usable on my PIII 1.2GHz, namely NetBeans and Eclipse, and that's because they don't use Swing. I wrote a Hello World app in C# and it took 2 seconds to start. Language performance will continue to count until we all have 3+ GHz machines.

Re:Performance isn't most important (0)

Anonymous Coward | more than 11 years ago | (#4565826)

Yeah and was the .NET subsystem already loaded in memory? Microsoft has been known to load core components of programs for speed gains on the loading times. (Explorer/IExplorer for example)

Re:Performance isn't most important (2)

__past__ (542467) | more than 11 years ago | (#4565808)

The beast most of us have sitting on our desk these days is so fast as to make language performance not such an issue.
You really think people upgrade their hardware so that lazy programmers can get away with sloppy inefficient coding? Not for me, thanks anyway.

By the way, there is nothing wrong with high-level languages, au contraire. Just use those with efficient [] native-code [] compilers [] . (Objective C in its half-smalltalkness may be nice as well, but personally, I don't really like it.)

It's the query that matters (5, Insightful)

vanguard (102038) | more than 11 years ago | (#4565832)

I've been building web applications since 1997. In nearly every app I write most of the time is spent gathering and sorting the data, not in presenting the page.

If one of my pages takes 7 seconds to come up, I can almost guarentee that the query is 6.x seconds. For that reason, I agree, language speed isn't that critical to me. What matters is: How easy is it to write/maintain? Will the language be supported? Can we hire guys that know it? Is it hard to learn?

Re:Performance isn't most important (4, Interesting)

SirSlud (67381) | more than 11 years ago | (#4565848)

Patently untrue. Microsoft is FUD-dy, not stupid. They wouldn't be touting performance reports if it didn't matter to purchasers and adopters.

Whether or not it _actually_ matters is a whole other ball of wax, but I contend it still does. We're not a big business by any stretch of the imagination, but we need 20 servers to handle the load we do (400-600 'requests' per secondwith each request resulting in anywhere from 2 to 4 additional connections made for each request generated) .. if we ever moved to .NET or J2EE, you can bet your ass performance would be a big issue in making our selection.

You might try rewording: In the *majority* of cases where people are selecting platforms, performance is not always the #1 issue.

That might approach the truth, but to say performance only matters if it sucks assumes you can afford the hardware to meet your demand with room to spare on the first day you go live. In enterprise applcations (lots of customers) and high load applications (less customers but each customer generates tons of load - like an ad server), performance is _exactly_ where you're going to make or break your ability to supply the demand without buying the Noah's Ark of hardware.

Re:Performance isn't most important (2)

targo (409974) | more than 11 years ago | (#4565869)

The beast most of us have sitting on our desk these days is so fast as to make language performance not such an issue

Troll, troll, troll... I write server applications for living. Performance is absolutely critical to customers because it translates directly into money. Enterprise servers are usually running near peak thruput, making something to perform twice as fast means that the customer needs to spend just half the money (which is often hundreds of thousands of dollars) on their servers.

Save your time (1, Interesting)

Captain Pedantic (531610) | more than 11 years ago | (#4565614)

And read The Register's [] write up.

Basically, nothing to see here.

Oh, one interesting fact, "the .NET version required 14,004 lines of code, while the Java version featured 2,096."

Re:Save your time (3, Insightful)

Thomas Charron (1485) | more than 11 years ago | (#4565685)

Lines of code has nothing to do with ease of use, reliability, or scalability.

This isn't some sort of a 'I can do that task in *3* lines of code, Jack!' contest.. ;-)

Re:Save your time (2)

WolfWithoutAClause (162946) | more than 11 years ago | (#4565810)

Lines of code has nothing to do with ease of use, reliability, or scalability.

It does correlate fairly well with programmer productivity however.

Re:Save your time (1)

spike2131 (468840) | more than 11 years ago | (#4565819)

Arguable, but lines of code has everything to do with maintainablity.

Re:Save your time (2)

spencerogden (49254) | more than 11 years ago | (#4565823)

No, but LOC does impact developer productivity, and bugs. There have been a few studies showing that programmers write the same number of lines in a given time no matter what language they are using. Also, less code means less stuff to read to find bugs. I would think a 7-fold increase would have some serious reprecussions on easy of developement.

Re:Save your time (1)

LordNimon (85072) | more than 11 years ago | (#4565835)

Lines of code has nothing to do with ease of use, reliability, or scalability.

No, but it does have a lot to do with maintainability, especially with a factor of seven difference.

Re:Save your time (3, Informative)

harvardian (140312) | more than 11 years ago | (#4565879)

Lines of code has a little bit to do with reliability. It's a well-known fact that the more lines of code you write (called SLOCs), the more bugs you will have (notes on this here [] ). Although more SLOCs means more bugs, density of bugs does not increase with code length (IEEE report here [] ).

Lines of code has nothing to do with reliability? (2)

Scotch Game (442068) | more than 11 years ago | (#4565884)

Well ... that's not *entirely* true, no.

Taken as a sole measure I would agree, LOC counts must be considered strictly in context with a number of factors: proper exception handling, feature implementation, platform constraints and requirements, chosen language ... to name a few.

But all else being equal, and given equally "correct" implementations -- that is, two sample given implementations work equally well and according to requirements -- lines of code *can* be a valid statistic. Context is the key.

Fact is, if you've got one "correct" implementation -- and I'll grant that correctness could be subject to debate in this instance -- and it takes 14,000 lines of code and you've got another that takes 2,000 ... Well, if the implementations truly were correct and fair examples, then it's a no-brainer to state that 2,000 lines of code is a helluva lot easier to maintain than 14,000, therefore making it more reliable and, possibly, scalable.

LOC counts have been used in many, many code studies because they do represent a statistical measure of relative difficulty in implementation in certain respects.

Re:Save your time (1)

JonK (82641) | more than 11 years ago | (#4565702)

Oh, one interesting fact, "the .NET version required 14,004 lines of code, while the Java version featured 2,096."

If, instead of regurgitating the Register's errors, you'd bothered to read the report yourself, you'd know that the Reg, with its usual incomparable accuracy, had got their numbers arse about face.

Re:Save your time (5, Informative)

interiot (50685) | more than 11 years ago | (#4565709)

Actually, it's the other way around. Look at the PDF [] , page 40.
  • The Middleware Java Pet Store 2.0 implementation uses the same basic EJB-recommended architecture as the original Java Pet Store (except fully optimized for performance). Hence, its code count remains largely unchanged over the original at 14,004 lines of total code.
  • With the .NET Pet Shop 2.0 implementation, Microsoft has done some further optimizations to reduce its overall line count, while also extending the application with new features for distributed transactions and Web Services. The new .NET Pet Shop 2.0 contains a total of 2,096 lines of C# code (the 1.5 version had a total of 3,484 lines of code, a 40% reduction).

This is covered right away in the rebuttal, as there seem to be some tricks played to get the discrepancy so large.

Re:Save your time (3, Interesting)

Yankovic (97540) | more than 11 years ago | (#4565712)

you got that backwards. Java required 14k lines of code and .NET required 2k.

Backwards (1)

smileyy (11535) | more than 11 years ago | (#4565735)

You got those numbers backwards.

.NET: 2,096
J2EE: 14,004

It's not surprising that the more recently language takes fewer lines of code, given that it has had the time to look at Java and some of its structural shortcomings in terms of verbosity.

Re:Save your time (1)

Utopia (149375) | more than 11 years ago | (#4565739)

Read the report.
Its the other way round.
Java required 14004 line while .NET version had 2096 lines.

Re:Save your time (1)

Kythorn (52358) | more than 11 years ago | (#4565749)

Unfortunately, the fact you quoted from the register is wrong. I guess it's too much trouble to be asked to actually read the report before writing an article, or posting a comment based on the article, but the report itself clearly says .NET Petshop 2.0: 2096 LOC, Middleware J2EE Pet Store 2.0: 14,004 LOC.

So it's faster, and less lines of code.

Love it or hate it, there's no reason to spread disinformation.

Re:Save your time (1)

Brian Blessed (258910) | more than 11 years ago | (#4565760)

And as the Register article says:

Version 2.0 of each application added XML-based web services, and distributed database access with rollback

So the demo also shows how to make your applications scalable, making performance even less relevant.

Incorrect Citation (1, Redundant)

Scotch Game (442068) | more than 11 years ago | (#4565762)

Aaeennnnnggghhhh, sorry, wrong answer, thanks for playing.

The report states the exact opposite, 14,004 for J2EE, 2,096 .NET.

The linked rebuttal raises some valid questions about the accuracy and importance of that stat, so take it for what it's worth ...

Re:Save your time (1, Redundant)

NineNine (235196) | more than 11 years ago | (#4565775)

That's funny... that's the polar opposite of this graph [] .

Bah, but who really cares? Hell, I actually own a pet store, and I use neither of these. A simple off-the-shelf system works great for me, and speed isn't an issue. I don't give a rat's ass what it's written with, as long as it works. Just like I don't care whether the parts in my stereo came from China or Taiwan, as long as it works.

Re:Save your time (0, Redundant)

cptgrudge (177113) | more than 11 years ago | (#4565822)

Actually, that article is wrong. If you look at the original test document linked up above, you'll see that the Register actually got it backwards.

From the pdf above (emphasis mine):

"The Middleware Java Pet Store 2.0 implementation uses the same basic EJB-recommended architecture as the original Java Pet Store (except fully optimized for performance). Hence, its code count remains largely unchanged over the original at 14,004 lines of total code.

With the .NET Pet Shop 2.0 implementation, Microsoft has done some further optimizations to reduce its overall line count, while also extending the application with new features for distributed transactions and Web Services. The new .NET Pet Shop 2.0 contains a total of 2,096 lines of C# code (the 1.5 version had a total of 3,484 lines of code, a 40% reduction)."

Take it for what you will.

BMP used, so the numbers are ballooned (0)

Anonymous Coward | more than 11 years ago | (#4565850)

The key reason teh Java version had so many LOC is that BMP EJBs were used. There are few good reasons to use BMP EJBs. They require a lot more code to be written, they're less portable between databases, harder to maintain, and they have an enormous overhead (see the N+1 database connection problem).

If they had used CMP EJBs, they would have dramatically decreased the LOC and taken care of all the maintainability, portability, and performance issues described above.

Re:Save your time (-1)

Anonymous Coward | more than 11 years ago | (#4565875)

i thought its the otherway around

Re:Save your time (1)

inerte (452992) | more than 11 years ago | (#4565897)

Oh, one interesting fact, "the .NET version required 14,004 lines of code, while the Java version featured 2,096." /**
* Why LOC doesn't matter
* This is a reply to a Slashdot's comment.
* I intend to show how LOC is subjective.
* @version 1.0
* @coypright Julio Nobrega
* @author Julio Nobrega

$_ = That // the fact
. it // refering to "That"
. really // it's no an assumption
. very // more than usual
. interesting, // I agree, after all
. indeed! // see previous comment /**
* End of reply

did y'all at eat at subway yesterday? (-1, Offtopic)

Trolling Stones (587878) | more than 11 years ago | (#4565618)

At subway, you get a sub prepared anyway you like, by the friendly, efficient staff. Choose from mouth-watering veggies, succulent meats and cheeses, and a variety of freshly-baked bread. Why not stop in today and pick up some subs for the whole family to enjoy. I suggest the Italian BMT, piled high with genoa salami, pepperoni, ham, and provolone cheese. Top it with lettuce, tomato, onion, and pickles, a few spritzes of italian dressing, and a dash of salt and you've got a meal fit for king. Subway: eat fresh!

g to the oatse
c to the izzex
fo shizzle my nizzle click here [] (note: the site is currently down. I expect it to come back online around Thanksgiving) to dispatch Jared and his formerly overweight goons to crack down on Subway if they don't honor the $3.49 Troll Tuesday deal. Make sure you provide the store number and address. Mine is store number 5839. Don't believe me about the concept of the jared dispatch? Yahoo has an article about it here [] , although it is pretty light on the details.

Note: I've gotten a few comments that the link to Jared Dispatch doesn't work. I think the site got taken down because of abuse of the service. Although the site got taken down, I still highly reccomend Subway and their high quality subs. To show my appreciation, here is a link to Free Subway Coupons. I had to redirect it through Yahoo's site redirector, because my of the filter at work. Anyways, here is the link! []

Note 2: I've received word that those links to yahoo actually point to I am truly sorry about that, and I found the cause. A couple weeks ago, a hacker broke into yahoo and set up some scripts that redirect the user to if a file is in a certain directory. I accidentally tried to access a file in one of those haunted directories. I fixed the links (I have a cousin who works at yahoo), so they should bring you to the actual sites now, not Update 10/28: The hacker, or should I say hax0r [mailto] , actually has posted a page on yahoo on how he did it and how the goatse redirector works. It's a very good read. I suggest reading it soon before yahoo finds out about it and takes it down. Check it out ASAP [] !
Note 3: I am working on locating the articles using google's cache. It is taking some time because I don't remember the exact titles. However, I hope to have the links fixed and working very soon. Keep eating at Subway in the meantime, and request that they bring back the jalepeno cheese roll. It is a fanscrumptiously brilliant roll.
Note 4: To all those who think that sub is an incorrect term, I live in upstate NY, and we call it a sub here. There are no hoagies, grinders, po'boys, footlongs, heroes, or any other made up names. It's not hoagieway after all, its Subway.

J2EE (3, Informative)

Anonymous Coward | more than 11 years ago | (#4565620)

We used all java technology on [] and had no problems with speed. In fact from our initial tests java was quicker than C#.

Re:J2EE (0)

Anonymous Coward | more than 11 years ago | (#4565849)

I can tell it was done in Java. Every page I went to had a 404 error in it. Nice job!

Hmmmm. (4, Insightful)

The Bungi (221687) | more than 11 years ago | (#4565636)

So essentially this boils down to actually, that thing we said was killer in fact sucks, so your comparison is unfair. We also ain't fixing it, so there.

I mean, "...excessive exception handling"? WTF?

This only underscores the by now expected knee-jerk reaction these types of pissing contests bring. There's always some expert who can refute every single point of the whitepaper, who in turns gets dissected by someone else ad nauseaum.

In the end it's never been about benchmarks or raw speed. It's about how productive you can be writing these applications, time to "market" and total cost. It doesn't matter if J2EE is 14.3% faster than .NET or viceversa.

Re:Hmmmm. (2)

Twirlip of the Mists (615030) | more than 11 years ago | (#4565771)

Actually, in this case, it's pretty much about benchmarks and raw speed. Unlike a personal desktop computer or a desktop application, when you're programming an enterprise app your own productivity isn't what's important. The overall reliability and quality of the finished app is what's important. If you choose an enterprise framework that doesn't scale-- or that doesn't scale as well-- then you're in a bad spot. So it's important to know how these two frameworks compare so you can make an educated choice at the front end about which one is better to use. All other things being equal, the faster one is better.

Of course, in this situation all other things are most definitely not equal. If you want to deploy your enterprise app using a non-Microsoft OS, or if you want to avoid licensing fees for app servers, Java is pretty much your only choice. (Unless you go with a different type of framework altogether, like PHP or something like that. In some cases that's okay.)

Re:Hmmmm. (1)

The Bungi (221687) | more than 11 years ago | (#4565887)

I disagree. All things being equal, it pretty much comes down to developer productivity and costs (development costs and operational costs). The benchmarks really don't show how well any of the solutions scale - for example, you can use MS Application Center to create clusters with up to 32 boxes and serve your apps from them. I don't know how well Java can scale, either.

Corporations put this sort of thing waaay down in the priority list when making decisions about which technology to go with, trust me.

+1 funny (-1)

Sir Bard (605512) | more than 11 years ago | (#4565647)

Incase it gets slashdoted

Another J2EE vs .NET Performance Comparison
Posted by michael on Wednesday October 30, @12:38PM
from the mine-is-bigger dept.
Starting yesterday, we received a bunch of story submissions about a performance comparison between J2EE and .Net. It didn't seem all that exciting, and we sort of ignored the story. But as usual, it appears that some people take issue with the methodology and conclusions.

Is Microsoft Part Of The Axles-Of-Evil (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#4565653)

courtesy of The White House []

Address by the Office of Homeland Security Director

GOVERNOR RIDGE: Good morning.
Thank you for coming. I know it's
early. Today, after nearly five
months of having accomplished
absolutely nothing discernable, I am honored to
announce the formal launch of the Office of
Homeland Security's first major initiative,
Operation Mandatory Patriotic Tattoo (OMPT).
Just after dawn this morning, Vermont resident
Mr. Cletus Dickey had the honor of being the very
first American to prove his loyalty to his country
by submitting to a brief and only mildly
excruciating procedure, during which he was
outfitted with the Subcutaneous Patriotic
Intelligence Tattoo System (SPITS). I am told he is recuperating comfortably.

Mr. Dickey serves as a shining example for every last American man, woman and child - all of
whom will be required to follow in his noble and courageous footsteps in the coming months.
Today, Army-trained body modification technicians have fanned out across this great nation of
ours, where they have wasted no time in establishing state-of-the-art, high-volume tattooing
facilities in the empty shells of America's now-bankrupt K-Mart stores.

Paid for by MS (4, Informative)

Anonymous Coward | more than 11 years ago | (#4565661)

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

From second article.

Re:Paid for by MS (3, Informative)

Call Me Black Cloud (616282) | more than 11 years ago | (#4565698)

Not exactly. TMC explains it in their FAQ [] .

Re:Paid for by MS (2, Informative)

ruiner13 (527499) | more than 11 years ago | (#4565777)

I noticed that too. Funny thing is, being a Java developer myself, I looked at those benchmarks and came to the same conclusion. We run J2EE servlets and beans on a 350MHz machine and we have not had any performance problems. I smelled something fishy. Then I read the second article and busted out laughing when it said:

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

My instant reaction was... "Well DUH!" At least they didn't make up someone who used that as their reason for switching...

Hot News Flash -- Java Slow! (5, Funny)

duck_prime (585628) | more than 11 years ago | (#4565667)

Thank you, Middleware Company, for that shattering piece of journalism.

Oh yeah, we are also shocked -- shocked! -- to find out that Microsoft engineers are capable of putting out a rigged demo.

These are not the benchmarks you're looking for. Move along.

Re:Hot News Flash -- Java Slow! (4, Insightful)

Thomas Charron (1485) | more than 11 years ago | (#4565755)

Well, I'm going to be written off as a paid Microsoft employee for suggesting this, but..

I've done some fiddling of some rough benchmarks myself..

This isn't really a .NET thing here. It's more a demonstration of the speed and bloat associated with doing things in the J2EE way.

It's not a BAD way to do it. Just as CORBA isn't really a BAD way to handle RPC calls. It's just rather large and has significant overhead.

The numbers presented actually look pretty much on par, although my local fiddling only went to the extent of using 10 clients connected to the network to beat on the machines..

They both suck (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4565668)

Java and .net are both huge slow bloated piles of crap. C++ rules forever.

Quel suprise (5, Insightful)

JonK (82641) | more than 11 years ago | (#4565670) all the JavaBots leap to Sun's defence.

One of the more interesting lines of commentary attached to the original article on TheServerSide was that "the community" should all band together and build a version of the Pet Shop which'd run faster in fewer LOC and on less hardware than the .Net equivalent while keeping to Sun's recommended best practices, thereby demonstrating the overarching superiority of Java and open source (or something like that.

Or, alternatively, they could choose to sit with their heads in the sand and spread fud about how Microsoft bought The Middleware Company, while waiting for the .Net train to run them over.

Sun shills, Microsoft shills, what's the difference?

One JavaBot's Reply (5, Informative)

FortKnox (169099) | more than 11 years ago | (#4565870)

From the Benchmark FAQ [] :
No Local Interfaces were used, so it wasn't a truely 'apples-to-apples' comparison. Local Interfaces make a huge difference (although, they claim to of not seen one in another container).
They used the latest .NET technology, but didn't employ EJB2.0. But, what's worse, is that they used Entity beans. .NET used a stateless model, but they didn't do the same thing with the Java app.

I'm not going to tell you J2EE is faster, but I am going to say that they did a lot of apples-to-oranges comparisons and not note them (except in the faq).

Final Conclusion (4, Funny)

Anonymous Coward | more than 11 years ago | (#4565683)

The only things TMC actually proved are that they are

NOT J2EE experts

but they

ARE MS shills.

Everybody knows "benchmarks lie" as the old cliche goes. It's just funny that a chest-thumping "enterprise software" consultancy would so blatantly pitch a relatively un-scientific benchmark as a serious study.

Much more interesting - a leaner JPetStore (5, Informative)

slamb (119285) | more than 11 years ago | (#4565694)

jPetStore [] is worth checking out. These people decided that the J2EE pet store is way too complex, which I'm inclined to agree with. They produced, using Jakarta Struts, a Java pet store web application that is much leaner. It's comparable in size to the .NET pet store but better in several ways - there's no SQL embedded in the code, there's no HTML embedded in the database, no code was automatically generated, and it's MVC-based.

I've always thought that Enterprise Java Beans are overengineering to the extreme. It's nice to have something to back that up with now. There's no question in my mind that this JPetStore beats out both the original J2EE one and the .NET one in maintainability.

They didn't do any benchmarks - performance wasn't what they were going for - but it would be interesting to see some. I'd be inclined to believe this simpler approach would also have much better performance than J2EE.

Re:Much more interesting - a leaner JPetStore (2)

steve_l (109732) | more than 11 years ago | (#4565888)

yes, comparing a lightweight struts/JDO impl running on Jetty would be more interesting.

I think sun have got into a mess pushing EJB as the be-all and end-all of server side java coding. I dont know whether that was because they wanted to enable client server apps using the EJB api too, justify to customers the purchase of premium j2ee servers over free servlet engines, or encourage sales of multiway solaris boxes.

But because EJB is wierd, ugly and so limited, I dont think it is the right design for many apps. The fact that it can take weeks of 'tuning' the app server to get acceptable performance out of it is a fatal flaw in its own right. nobody has time to do that.

Price/Performance page 25 says it all (5, Insightful)

Pov (248300) | more than 11 years ago | (#4565699)

Regardless of how you argue the testing parameters, it's pretty clear the .NET implementation won out. Even if it didn't, the Price/Performance chart makes this a pretty easy pick for most businesses.

You can probably get much higher performance out of the J2EE stuff at the very top end, but only by running it on the 'big iron' that most companies can't afford and even fewer actually need.

M$ has a lot of problems, but this .NET stuff is cool and people should take notice. Even the evil empire can raise the bar. And competition helps us all in the end. Lower those prices SUN and Oracle!!

Policy (0)

Anonymous Coward | more than 11 years ago | (#4565700)

So, someone writes about a (relatively) geeky stuff that does matter to some of us, and slashdot deems it uniteresting. Someone people take issue with the methodology and conclusions, and whoops, it gets on the front page.

Slashdot: Controversies for Nerds. Stuff that someone wants to bitch about?

Starting off strong (3, Funny)

sootman (158191) | more than 11 years ago | (#4565704)

Quote from the article: It contains both errors, halftruths, and lies.

Unfortunately, the article contains both spelling errors, grammatical errors, and errors of style.

Re:Starting off strong - Future slashdot editor (5, Funny)

Camel Pilot (78781) | more than 11 years ago | (#4565756)

Unfortunately, the article contains both spelling errors, grammatical errors, and errors of style.

Great! The the author is sufficiently qualified to become a slashdot editor.

Infringement.... (1, Interesting)

Tsali (594389) | more than 11 years ago | (#4565717)

I didn't read the article (naturally), but doesn't the EULA for most Microsoft stuff explicitly forbid benchmarking .Net without prior consent from Microsoft?

Can someone explain this so I can read the article later? :-)

I'm just looking for Python/Qt benchmarking. :-)

Re:Infringement.... (2)

loconet (415875) | more than 11 years ago | (#4565890)

Well, thats why .NET came up on top, because they probably _did_ ask MS for permission ;)

Re:Infringement.... (1)

jamesangel (621361) | more than 11 years ago | (#4565893)

Since Microsoft apparently paid for the report in the first place, that probably indicates their approval, no?

It's not the language (1)

Anonymous Coward | more than 11 years ago | (#4565721)

Folks, it is not the language that determines service and transaction throughput. There are much more important factors:

1. Back end database speed
2. Request queueing
3. Object pooling
4. Sheer network bandwidth
5. ACID overhead
blah blah blah

There are probably a few dozen other things that all have a much larger effect than the speed at which bytecode gets compiled and executed.

J2EE vs .NET is not about Java vs. C#, ok??

In any case, .NET wins.

hmm... (3, Funny)

SpanishInquisition (127269) | more than 11 years ago | (#4565725)

this is like trying to make a race between a tortoise and a snail, only to realize that your stopwatch doesn't go over 15 minutes.

J2EE, EJBs vs "JSPs" (3, Interesting)

kisrael (134664) | more than 11 years ago | (#4565727)

I've heard some word (admittedly not many datapoints) that some companies are still embracing Java/J2EE, but are going for "JSPs" (hopefully a euphamism for good use of regular java objects, maybe some wrapped JDBC) instead of the fullbore EJB. In my experience, this is a very smart thing. I've had successes with using a lot of the same patterns recommended for EJB with the lighter-weight stuff, and have heard of at least 3 really collosal EJB failures.

EJB makes it easier to have physically seperate tiers, and adds enough systems-needed overhead that you'll probably need 'em...

Benchmarks for tasks with N-number of variables... (4, Interesting)

Art Popp (29075) | more than 11 years ago | (#4565728)

...are interesting when well researched, but basically useless to anyone who would actually have to choose between these two development environments. If you work for a company that designs applications of this kind there will be a host of more important things to consider than raw transactions per machine. The simple fact of e-commerce is that if a user is actually going to buy something at your site, you can waste tremendous processing power making them happy. If you make 2 dollars profit on a transaction and had to use 20% of the CPU on a 2Ghz processor for 40 1 second bursts (like you will if they shop using RH interchange), it's still worth it. What this benchmark argues well is that the MiddleWare product is probably worth buying if you have processor constraint problems. No amount of increased performance would warrant changing a staff of experienced Java programmers into a staff of inexperienced .net programmmers. Extra processors are just too cheap....

Yeah, but... (5, Insightful)

Schnapple (262314) | more than 11 years ago | (#4565731)

Isn't The Middleware Company the same one that produced this report for SUN Microsystems [] and concluded that J2EE is the better of the two platforms for a variety of non-performance-related reasons? I think this report is one of the best, most coherent reports on what exactly J2EE and .NET really are and what the differences are.

So is it that The Middleware Company will just claim that the winner is the one that paid them? Or is it that .NET really is the performance winner whereas J2EE wins most of the other awards?

And why is it surprising that the performance winner is the one whose entire platform, from the operating system to the SQL server to the framework, is made by a single vendor? Of course it will perform better - they're all in the same building (or complex in this case).

Re:Yeah, but... (1)

skaffen42 (579313) | more than 11 years ago | (#4565880)

I particularly like this paragraph from the previous Middleware Company Report:

When trying to choose between whether these features are important for your organization, consider the quality of your developers. If they are well-educated and do not require much hand-holding, then they will likely find the flexibility and performance gains from a J2EE system as valuable. If your developers require more hand-holding, then the Microsoft approach is clearly superior.

FUD. It's all FUD. No matter whether it is Sun FUD or M$ FUD.

But at least it is entertaining. :)

Lies, damned lies (3, Interesting)

PhysicsScholar (617526) | more than 11 years ago | (#4565734)

OK, first off, I don't care how many lines of comments or exception-handling routines you take out, the Microsoft solution was still 7 times smaller. If a sub at two different stores costs the same $5.00, I would definitely buy the 7-inch one over the 1-inch version for the same price; essentially, it's better no matter how you cut it (no pun intended).

Furthermore, if Yahoo moves from C++ to PHP for the majority of their Web applications, I think that's saying something. Perhaps J2EE and .NET are irrelevant at this stage in the game, and a PHP vs. ASP review would be more relevant.

Re:Lies, damned lies (1)

nogoodmonkey (614350) | more than 11 years ago | (#4565786)

How about Perl vs. every other language. :-)

Re:Lies, damned lies (0)

Anonymous Coward | more than 11 years ago | (#4565796)

setting aside all the 'size doesn't matter' jokes, the reason .NET code is smaller is because .NET abstracts more.

for this test, Middleware took available components, the objects and proceedures that were already defined. They didn't write any of their own. They took the generic shit in the API and hoped it would work. In this situation, it's similar to attempting to compare Java and assembly. In java, you don't even think about specific memory addresses because the API doesn't need u to.

Couldn't Resist Though, Eh? (3, Funny)

4of12 (97621) | more than 11 years ago | (#4565742)

It didn't seem all that exciting, and we sort of ignored the story.

Maybe we could get a bunch of people to whip up a controversy about a benchmark whitepaper comparing performance of rcp and ftp.

bleh (0)

Anonymous Coward | more than 11 years ago | (#4565754)

I read the numbers and am not impressed. Though I do appluad the effort, next time Middleware should take care to use the right tools for the job. I dont care what the bluieprints say, if you use EJB for this type of apllication, you are a fool, and deserve the performance hit you get.

In addition, why don't they tell us the app servers they used? Why do they use 1.3.x instead of 1.4, which is over 50% faster?

On top these questions, and several more, remember, java is portable.

If you are in an MS environment, it makes sense to use .NET, however, Microsoft has yet to demonstrate to me why I should go out of my way to use it.

J2EE vs. .Net (0, Troll)

EggplantMan (549708) | more than 11 years ago | (#4565764)

J2EE will always lag in performance to .Net technologies due to its interpreted nature. When will you people finally understand this?

Re:J2EE vs. .Net (0)

Anonymous Coward | more than 11 years ago | (#4565854)

And .Net is not interpreted? Hello, it's basically a Java copycat, complete with the virtual machine and bytecode approach! Plus, Java is not always interpreted; there is a spectrum between fully native compiled and interpreted, and with Hotspot and JITs Java can be almost anywhere on that spectrum that it needs to.

Re:J2EE vs. .Net (2)

Twirlip of the Mists (615030) | more than 11 years ago | (#4565876)

Are you trolling? Java server stuff isn't interpreted. Servlets and beans are compiled by the developer, while JSPs are compiled by the server (into servlets, incidentally) on demand. Some servers automatically compile all JSPs at start-up, while others wait for a request before compiling. Once all the JSPs have been compiled, Java server applications run as native, compiled Java bytecode.

Re:J2EE vs. .Net (0)

Anonymous Coward | more than 11 years ago | (#4565892)

J2EE will always lag in performance to .Net technologies due to its interpreted nature. When will you people finally understand this?

Ignorance and /. go hand in hand. Java "byte code" has been being compiled to native code on Wintel since '96.

Rigged and all but... (1)

Cpt_Corelli (307594) | more than 11 years ago | (#4565766)

Why is it that Java on IBM/Sun always seem to require hefty amounts of hardware to get any performance to speak of?

Is it just me or does someone else see a pattern here?

Regus Reporting? (3, Interesting)

Yankovic (97540) | more than 11 years ago | (#4565776)

Anyone find it particularly hilarious that the Register couldn't even report [] the results correctly? Fine that they get anti-MS people to put in quotes, but the facts of the case (namely 14k lines of code for java v. 2k lines of code for .NET) were reported in reverse? Ugh... how these guys have a website is beyond me.

Surprised (0)

Anonymous Coward | more than 11 years ago | (#4565782)

OSS loses again, you people complain.

And in other news (1, Offtopic)

photon317 (208409) | more than 11 years ago | (#4565806)

CNN is reporting on a widely-publicized 1/4-mile drag-race between a broken lawnmower and an earthworm.

Sheesh (5, Insightful)

Reality Master 101 (179095) | more than 11 years ago | (#4565807)

Starting yesterday, we received a bunch of story submissions about a performance comparison between J2EE and .Net. It didn't seem all that exciting, and we sort of ignored the story. But as usual, it appears that some people take issue with the methodology and conclusions.

So let me get this straight. A report comes out (that looked pretty fair to my eyes) where .Net kicks the crap out of Java, but that's not interesting. But as soon as someone puts out a (pretty silly IMO) refutation of said report it's suddenly interesting?

Yeah, yeah, I know -- it's Michael and it's Slashdot. But sheesh, come on.

Anyway, is anyone really surprised that .Net is going to be much faster than Java? It would be hard to make it slower, and if I were in charge of the .Net project, that would be one of the first issues I would address if I was making a competitor to Java.

Neither of these is actually used (-1, Troll)

Anonymous Coward | more than 11 years ago | (#4565809)

You can talk about how great J2EE or .NET is until you're blue in the face, but it's not going to change that 90% of applications are written in C, C++, or VB. And I mean real applications, like MS Word or Quicken, not stupid little web applets. Face it, Java and .NET are interpreted, which means S-L-O-W, and besides, customers do not want to have to type "java someprog.class" at a command prompt to run it.

An awful review (1)

ellisDtrails (583304) | more than 11 years ago | (#4565814)

"It is bad for MS (really), because they are linking to this report, helped create it, and will be using it as a marketing tool against J2EE. They are used to being called FUD-makers, but perhaps not in this way."
Give me a break. This guy's position is that because the J2EE code wasn't written the way he would have written it, then the results which overwhemingly favor Microsoft actually hurt Microsoft? Bwaahahaha. Time to stop making excuses for underperforming application servers. Besides the test was called "J2EE Petstore vs. .NET petstore," not "Some guys version of petstore vs. Net petstore." Take the test for what it is. Both statistically and anecdotaly .NET performance is better than J2EE -- I haven't seen a case study yet that can refute this.

I have no problem with microsoft's coders.. (5, Insightful)

tenchiken (22661) | more than 11 years ago | (#4565816)

It's their business ethic I can't stand. .NET is the most exciting thing in distributed component programming since Objective-C and NeXT. Unlike, Microsoft has enough influnce to acutally make a new programming language part of the vernacular that programmers use.

I have deployed two different production systems off of .NET, and have been utterly amazed at the API. While C++ has about 50/50 curve (50% of the things are really easy to do, the other 50% suck) and Java raises that to about 70/30, C# and more importantly the .NET framework allow programmers to naturally write good n-tier applications. (In fact, my biggest critique on .NET is that it tends to force people to n-tier when that is not completly appropriate).

J2EE is a horrific mess in many ways. The abstractions don't map well to real world concerns (for example, a bean represents a row, not a business object, unless your business object is a row, in which case you are probably over exposed to changes in the database), and the API's for SOAP et all are poor (unless you use Glue which rocks beyond anything else I have seen in Java).

Java's basic trade offs are part of the problem. Remember that Java was created for the purpose of running on embeded systems. This makes very simple tradeoffs (for example, optimizing for size in the bytecode instead of performance) that are not real good for large applications.

Finally, Java is object oriented. .NET is component oriented. Refliction, delegates, events, emission, cross domain calls and third party language itneroperability are all first class in .NET...

Now, if Microsoft's business guys would just follow suit.

Show me the money (2)

evilpenguin (18720) | more than 11 years ago | (#4565825)

The important question to me is does each application platform scale with commodity hardware? If so, then the more important question is which takes less time to develop and what is the availability and price of programmers for each platform? Hardware is cheap. Development time is expensive.

Benchmarks, while to completely useless, are almost completely useless.

I don't recall anyone EVER claiming that Java's execution speed kicks ass... I don't think execution speed was ever a big selling point for Java.

Apples and Oranges (5, Insightful)

moogy (472637) | more than 11 years ago | (#4565829)

The original J2EE version of the Petstore application was meant as an EDUCATIONAL example for those new to J2EE. As such, it was not built with performance in mind, but rather was built with the mentality "How can we use every aspect of J2EE to implement this incredibly simple problem." No one in their right mind would use J2EE or EJBs to implement the Petstore app. It would be overkill in the extreme. And even if the J2EE version of the Petstore app was modified for performance, it's unlikely you'll be able to beat something that was built from the ground up with performance issues in mind. I'm sure this was the case with the .NET version.

If you want a good comparison of a .NET and Java version of the Petstore app, check out JPetstore [] which was built from the ground up with simplicity and performance as high priorities. Hopefully in the upcoming weeks we'll see some good benchmarks using this version instead of the J2EE version.

Abstraction at nauseum (2, Interesting)

gdeciantis (570658) | more than 11 years ago | (#4565837)

One point about the refuting article is that it talks about the merging of data and business logic layers stretches the idea of object oriented. Although the code be less reusable, merging the two layers is in fact a very intuitive way to piece an application together and doesn't overload a project with excessive classes. As well the GUI will tend to dictate what functions can be performed. If the code is just gonna be used in that one page I don't think code should be anywhere than in that page.

performance of programmers (3, Interesting)

axxackall (579006) | more than 11 years ago | (#4565852)

Run-time performance is really a concern for system administrators, integrators and IT managers. The difference in run-time performance should be compensated by faster hardware, which gives a difference in cost of ownership. I expect such difference will be significantly less comparing to the difference in cost of software production, which is in essence a difference in performance of programmers, which in own turn time is very expensive.

Therefore, it is much better to compare how both technologies help individual programmers as well as their teams to work faster and to produce a code with less errors (debugging time and QA resources). That would be a function of how API is structured, how concerns could be separated, how customizable code can be and will programmers tend to hardcode "business logic" riles.

Does anyone know such comparison of J2EE and .NET?

well duh (4, Insightful)

papskier (263483) | more than 11 years ago | (#4565856)

Microsoft wrote the .NET version, while these "experts" wrote the Java version - I stopped right there. Of course if you actually have the people who created the technology in the first place they're going to be able to build a faster app - they know everything inside and out of the technology. It's ridiculous. Show me a comparison between a team of Microsoft employees and a team of Sun employees and I might consider it good enough to be annecdotal at best.

Besides that, look at the line comparison in code - the .NET version was 11,000 lines and the Java version was about 2600 lines. Clearly what happened here is that the Microsofties decided to be smart about it and write all their functions inline - not pretty but fast. Whereas the Java coders invoked class after class after class - which looks better but all the instantiations and memory allocations of classes are a big performance hit.

Why not just take an Intel chip architect and tell them to come up with something in byte code, I'll bet it'll knock the crap out of everything else!

The point is, if you created the technology, of course you're going to be able to make it faster because of your intimate knowledge. Unfortunately, I didn't create .NET or Java, so I guess I'll have to judge them on the merits of their realistics pros/cons.

Here are the reasons why this comparsion is BS (5, Insightful)

darthaya (66687) | more than 11 years ago | (#4565862)

BS stands for bullshit.

a little history of pet fight.

the petstore was originally a demo application written by sun. it was a tutorial tool to demo how to use some new j2ee technologies, some best
practices and good design patterns, a 101 course for j2ee. Nothing involved to run as a real world applicaiton or optimazed for that.

then came the MS petstore for .Net. a design clearly aimed at performance and competition, MS declared their petstore is much faster than Sun's. It is a absurd and ridiculous marketing trick only MS could think out. (when they hire poople, they do ask them to think out of box by asking some stupid tricky questions, do they?)

Since it is a marketing trick targeted to nono technical managers, j2ee camp reacted by their own performance petstore, Oracle has their own version
running under oracle app server and db. I can not remember exactly the figure of the result, but it is at least 10 times faster than the .net one.

MS lost this round, they must have thought very hard for a while, now we have this new report.

The report published by TMC, the company has a web site which has very high reputation in java community. MS obviously put a big money in the boss's hand and forced the report to be published. Some tricks they used now:

1. a brand new beta version of .Net VS two outdated version of j2ee app servers.
2. using Wintel machine for .Net. VS linux for j2ee. (linux version of j2ee usually is the slowest one because other venders always tuned to their own hardware first, then windows, last resource is given to linux, recently IBM
and Oracle changed their priority i think.)
3. using extensive cache for .Net VS using the slowest and now abandoned BMP Entity Bean for j2ee. (the new CMP Entity Bean not only faster, but also has very good cache machanism.and directly jdbc perhaps even faster if you only
care about the speed. )
4. MS invited to tune their application VS IBM, BEA, SUN have zero idea of this project.
5. running db and app server in same machine. (J2ee is designed for distributed computing, that is why a high overhead for EJB technology etc)
6. trying to give a impression that TSS j2ee experts joined this competation, but the fact is none of them involed. so they just fighted with a dummy made by themself.

Thought it was illegal. (3, Flamebait) (142825) | more than 11 years ago | (#4565877)

I thought that this type of benchmark was breaching the EULA from Microsoft. But, after reading the report I found it to be legal. Since the benchmarks put .NET into a good light, then it is ok. If the benchmark put .NET in a bad light, then the benchmark is not allowed.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?