The Middleware Company (market leader in enterprise Java training and consulting) has performed a new comparison of the performance and scalability of J2EE and .NET based on the familiar Pet Store application. This time, the Middleware Company has re-coded the J2EE Petstore and optimized the implementation for performance. Their report show that .NET outperforms Java in most of the specific tests they conducted. Lots of discussion already here.
New J2EE vs .NET Performance Comparison Performed
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Good thing I am only using Java for desktop
)
And *no* – C++/C# wouldn’t be better for what we are doing…
take a look at:
http://java-game-lib.sourceforge.net/
Oh yeah…Java is known to be a real “rocker” on the desktop :-)))
But on topic : The fact that .NET outperforms Java big time is old news. That was the result in the first Petstore comparasion.
.NET is compiled and, thus, emphasizes performance. Java is interpreted (even if bytecode), but emphasizes other important factors, such as compatibility, modularity, existing code base, maturity, etc. Such a comparison isn’t completely inappropriate as there are surely companies evaluating technologies on performance above all else, but the comparison seems to imply that performance is the basis for worthiness of the technology.
Did you miss the parts about:
2 weeks for .NET tuning vs 10 for J2EE
1,500 .NET lines of code vs 14,000 J2EE
As for maturity, lets not go there. The more mature product should show its prowess in performance, integration time, and efficiency of design.
Obviously it has not done that in this test.
The almighty $ always draws the bottom line (where the CTO signs the dotted line):
Check out the price/performance comparisons. 5x better price/performance for TCO vs throughput/peak user load/error rate for .NET vs J2EE as a -worst case scenario-.
J2EE got wupped. Don’t build a petstore with this. As for other scenarios and application areas, that remains to be seen.
I’m not so naive that I don’t hear the arguments about being “tied in” to Microsoft.
I’ve used Java extensively, and now I’ve reached nearly the same level of proficiency with .NET.
At the end of the day, I just can’t bring myself to use Java any more. I just find the whole .NET experience, from C# to the framework to the development environment, to be vastly superior to Java. I have to write code day by day, and when I’m in the trenches I want to have the best tools I can have. Quasi-religious considerations of love or hate for Microsoft just don’t enter into it for me.
Java’s openness may be a good thing on some levels, but on others it’s produced an embarrassing, jumbled API soup. It’s a mess. .NET feels clean and well-integrated to me.
Enough said. Let the Java-heads (of which I’m an ex-) attack me.
>Oh yeah…Java is known to be a real “rocker” on the desktop :-)))
Please ‘KLAMATH’ – If you had actually looked at the link, you would have seen that it pointed to a OpenGL/OpenAL + Input and Vector Math library.
The performance of this Library is near native (‘cept the Vector stuff, which hasn’t been optimized yet)! The overhead added by Java (to increase productivity) is ignorable.
It’s funny how such reports can skew the view of Java Performance. When measuring performance there is a lot of factors to count in – not just Transactions Per Second or stuff like that. There is the whole development process too – including tools to produce.
The report clearly shows that .NET’s performance is superior to J2EE in that particular scenario… – But try doing a “typical” scenario on a Mobile device – and you’ll see that .NET fails superiorly, since no implementations are available… They will, but currently it isn’t possible.
It is a matter of choosing technology based on criterias (of the customer) – not because one is a M$ basher or a $un basher… – though it happens rather often…
We choose to use Java accompanied by native bindings for our game library – not (only) because we like java and its productivity increase over C++ – but because of its crossplatform possibilities. Something that .NET cannot give – and dare I say ever?
That said, I do believe that Java has some things (speed wise) to learn from .NET – which obvisously have implemented prejitted code successfully – something sun for a long time have said they wouldn’t do, since it isn’t feasible <insert long explanation here>…
> Good thing I am only using Java for desktop
)
> And *no* – C++/C# wouldn’t be better for what we are
> doing…
I wouldn’t be so sure about that.
In a few weeks, DirectX 9 will be released with a managed API for .NET. Performance is equivalent to native C++, and without nasty hacks like exposing pointers as the LWJGL does.
If OpenGL is more to your liking, there’s a .NET API for that too: http://csgl.sourceforge.net/
Isn’t it painfully obvious to everyone that Java is antiquated dotcom technology?
J2EE was designed for big giant Sun servers staffed by armies of Sun consultants. It makes no sense from any sort of cost analysis. It’s completely opposite from Moore’s law. It doesn’t work well on arrays of small cheap machines. The inherent complexity of J2EE is off the scale. All that complexity and so little inherent capability.
As a programming language, Java is nothing more than a pitiful subset of C++ saddled with a set-top VM design and knotty class libraries. Where’s the cool new capabilities? The Java byte code is not even as efficient as 10+ year old p-code. The Java garbage collector is definitely a union worker… either barely working or on strike.
Java + J2EE + UML = IT nirvana, right?
Or is that the new equation to keep the 80% IT project failure rate going strong?
All these years of Java hype and there still isn’t a good IDE. Well, other than J++ or Microsoft’s Visual Studio + J#.
All because Sun is so damn stupid they can’t figure out what “open standard” means.
The discussion link is unreachable… Good work, guys
> It’s funny how such reports can skew the view of Java
> Performance. When measuring performance there is a lot
> of factors to count in – not just Transactions Per
> Second or stuff like that. There is the whole
> development process too – including tools to produce.
Did you read the report? It covers other aspects like cost, lines of code, time needed for application configuration/tuning, stability under load, etc… and on every one, .NET is mopping the floor with J2EE.
> But try doing a “typical” scenario on a Mobile device –
> and you’ll see that .NET fails superiorly, since no
> implementations are available… They will, but
> currently it isn’t possible.
What’s a “typical scenario on a mobile device”? Java games? I don’t think so. A large amount of what is targeted at mobile devices is the same sort of Web content that this Pet Store reference app deals with. You can see this same sort of thing here on OSNews with the WAP link at the bottom of the page. ASP.NET has designers for mobile UIs like this that can tailor themselves to the target device automatically.
Regardless, if you do want to run code on a mobile device, the .NET Compact Framework is available in beta and should ship with .NET v1.1 soon. When it is released I wouldn’t be surprised if it kicks the crap out of Java on mobile devices as .NET is doing on the server side.
> We choose to use Java accompanied by native bindings for
> our game library – not (only) because we like java and
> its productivity increase over C++ – but because of its
> crossplatform possibilities. Something that .NET cannot
> give – and dare I say ever?
“Currently the LWJGL supports only the Win32 platform, and JDK1.4.” from http://java-game-lib.sourceforge.net/documents/tutorials/intro.html
Doesn’t seem too cross platform to me.
Cross platform for .NET is coming… http://www.go-mono.com/ .
Here my questions regarding the test:
a) Was it on a single server or on a cluster?
b) How about security?
c) How about stability and crash recover?
There are more issues in IT then RAW PERFORMANCE… and analysing a platform just for performance is (IMHO) very naive!
As for high scale operations (that are those targeted by J2EE), costs aren’t an issue, never where, never will be…
And comparing .NET to J2EE without comparing the application servers behind the sceenes and it’s hardware platform is a bit… incomplete and will lead to all kinds of misinformations as usual from those “benchmark” addictheads…
Cheers… and be nice when programming…
<<The discussion link is unreachable… Good work, guys
>>
Why am I not surprised? The discussion link is a jsp site 😉
>to J2EE in that particular scenario… – But try doing a >”typical” scenario on a Mobile device – and you’ll see that >.NET fails superiorly, since no implementations are >available… They will, but currently it isn’t possible.
There is one implementation from Microsoft that I use for developing – it’s called .NET Compact Framework – and it IS available and usable. As for J2ME (the Mobile version) – have you ever tried working with it? It’s painfully slow and it has so many bugs that I’ve no inclination to work with it anymore.
>It is a matter of choosing technology based on criterias (of >the customer) – not because one is a M$ basher or a $un >basher… – though it happens rather often…
I’m a registered VS .NET beta-tester and dev(as well as J2ME) and here’s the real truth about Sun and Microsoft – whenever I submit J2ME bugs to Sun – I get no replies, no reward, whereas Microsoft assigns and fixes bugs and mixups right away. As a user I would use the technology that has less bugs and more support – and, sadly, no, it’s not Java.
>We choose to use Java accompanied by native bindings for our >game library – not (only) because we like java and its >productivity increase over C++ – but because of its >crossplatform possibilities. Something that .NET cannot give >- and dare I say ever?
Hmm, when I think of .NET I think “cross-platform”. Did you ever try to get the VM license from Sun to build the VM for the new OS (or better to say the old one – BeOS :-). I tried – no reply at first, and then a firm NO. No VM – no cross-platformness for Java. As for .NET – CLI sources are open-sourced, and with some effort you can write a VM for .NET which will lead to cross-platformness.
> over C++ – but because of its >crossplatform possibilities. > Something that .NET cannot give
And why do I get a feeling that for you .NET is a C++ language and not a platform?
Save your questions/comments for when you read the report. Your questions are answered there, and it’s not just about raw performance. (Unfortunately, TheServerSide can’t seem to handle the current user load… gee, wonder why…
> As for high scale operations (that are those targeted by
> J2EE), costs aren’t an issue, never where, never will
> be…
Ahh, Sun, the dot in dot com…
Show me a company where ROI isn’t an issue and I’ll show you a company that doesn’t know what the hell they are doing. Cost is a big reason why Sun’s big iron is being replaced by clusters of Linux boxes.
All this report proves, is that two unnamed application servers are not as efficient on the Windows2000 platform as .NET is on the Windows2000 platform.
In my experience, ‘market-leading’,’state of the art’ j2ee servers are deployed on Unix systems, which are themselves optimised for the application servers.
I wonder just how impartial The Middleware Company were? We’ve all seen Microsoft paying for ‘research’ before now.
mauerj:
“In a few weeks, DirectX 9 will be released with a managed API for .NET. Performance is equivalent to native C++, and without nasty hacks like exposing pointers as the LWJGL does.”
Sure, but the .NET framework isn’t crossplatform – CLI *is*, but the framework isn’t, and never will be (completely).
Btw: Isn’t the managed code extension closed source, I am fairly certain that it hasn’t been ISO’ed.
“Did you read the report? It covers other aspects like cost, lines of code, time needed for application configuration/tuning, stability under load, etc… and on every one, .NET is mopping the floor with J2EE.”
Yeah, I read it – and your *absolutely* right – .NET *is* mopping the floor with J2EE… but I wasn’t talking about J2EE, I talked about Java and associated technologies
“…the .NET Compact Framework is available in beta and should ship with .NET v1.1 soon.”
As said, there is no product that could compete with J2ME, yet (ßeta doesn’t count – BitBoys have some ßeta products too
) – but I am happy to see some competition Real Soon Now 
. I can’t comment on either framework, since I haven’t used them – I just pointed out that M$ didn’t have a .NET framework for “small” devices.
“[LWJGL] – Doesn’t seem too cross platform to me. ”
No, because this is a young project – we’re still at alpha (0.2), but work is being done on linux and Mac OS X… We’re ready Real Soon Now
“Cross platform for .NET is coming…”
Ehm… NO! – I’ll wager my house that my homemade .NET program using WinForms and System.Data.SqlClient won’t work on mono. (I know they’ll be trying to create a wrapper around it…)
Cross platform CLI is comming – NOT .NET, there is a HUGE difference!
Wazoo:
Regarding your experience with J2ME feedback I am sorry to hear about that, but this hasn’t been my experience… (can’t speak about M$ support though – so can’t *really* compare)
“Hmm, when I think of .NET I think “cross-platform”.”
Too bad for you… You’ll be surprised when mono is ready… .NET isn’t crossplatform at ALL!
“Did you ever try to get the VM license from Sun…”
No, but some fellow BeOS developers has gotten it… – and besides, this has nothing to do about crossplatformness… a product can easily be 100% crossplatform, and only implemented on 1 platform… – I wouldn’t trust it, but still…
“And why do I get a feeling that for you .NET is a C++ language and not a platform? ”
Don’t know… ?
.NET is a framework, platform .
<flamesuit>^^ and a m$ cage, for the uninformed</flamesuit>
I’ll say this much – I *hate* M$ for being monopolistic, but I’d choose their solution any day of the week, IF it makes sense for a project! – otherwise I would choose whatever else makes sense…
(little preface: You can run java on big iron. Say, 16 CPUs with lots of disks via fiberchannel (or is it fibre channel?). In that configuration, java would beat .NET, because .NET doesn’t support the platform.)
But at the end of the day, .NET is useless for most comanies that are currently Java shops. The reason is strategic: these companies just don’t want to get in bed with Microsoft more than they have to.
That’s not to say there won’t be companies that will adopt .NET, but I am sure that most won’t, and not because of technical reasons. MS is going to reap what it had seeded for many years.
Mark my words, flame if you want but mark my words and check back in 2 years from now.
Wow, as a Java die hard I was rather disheartened by this report. Don’t get me wrong, I program in many languages, but I’ve always had a fondness for Java. One of the things I’ve always hated about java is the performance issues. On mathematics code, I don’t get by with too much overhead, but anything with GUI’s or socket calls can be a mess on the performance. I’ve been toying with the idea of switching to C#, hoping that the API would be delivered truly cross platform. I’ll keep holding my breath on that one though.
I wonder why someone like MainSoft doesn’t buy the rights to the class libraries and redeploy them on X/Unix & X/Linux. Also I would like to see Apple, or MS/MacBU, do the same for OS X.
Unfortunately for the anti-MS zealots, Microsoft did cross platform right. Unfortunately they aren’t releasing it to make it cross platform. Perhaps the Justice Department should have concentrated on this, instead of worrying about the 10 year old issue of web browsers in the operating system of today. It’s a moot point now.
http://www.corel.com/ssclii/
stick with python and scheme
real anonymous functions, not delegates or methods in anonymous classes. It’s pretty stupid that neither the .net clr nor the java vm added support for that.
J2EE is good but slow…
Sun will get their butts in gear or MSFT will run them over!
ciao
yc
I wonder what he got to say about this 🙂
God, you people. Must you make Java and .NET religions? Anything against it must be flamed heavily? Microsoft is not evil. If Sun had the same market power as Microsoft, trust me, they wouldn’t all nice and holy.
First of all, J2EE is good, but slow technology. Its pitfalls are well known. J2EE is not the only way to go in application server field in Java. There are other choices. For instance GLUE framework for Java by Mind Electric (http://www.mindelectric.com) already beats .NET performance in web services.
Also, the platform tested is Windows. Windows have OS level optimizations for .NET, and it is clear from the tests that MS professional worked 2 weeks on the system to optimize .NET installation. Also, Java 1.3 used in the test results, with a note that states Java 1.4 increases throughput 50 percent. I think that the tests will not yield the same results on Linux etc.
Interestingly, I have come accross some report related with Swing being faster than Windows .NET on the following site:
http://www.javalobby.org/thread.jsp?forum=61&thread=5488
I really do not care much about which is being faster much, since the speed is enough in many cases. There are more important factors rendering .NET unviable.
It is not cross platform (don’t say ‘yet’, speak when it is supported on Mac OS, Linux, etc fully.), and it is totally controlled by MS, who proved to be untrustable myriads of times in the past. And .NET is much more expensive than open source J2EE implementations.
The only thing that I ever found really slow to a point of being annoying in java are GUIs. For the rest with a 1.4 VM you get really good performance now compared to what it once was. Even swing is a bit faster now, but it’s still a pain and just doesn’t look professional.
I would recommend to anyone bitching about slow java GUIs to download Eclipse (eclipse.org). For those who don’t know about it eclipse is a java IDE made by IBM. Besides the fact that is entirely free, open-source and a _really_ excellent tool it is also a demonstration for the SWT toolkit. Short said SWT is a native library ported on several platforms that allows java programs to have a fast and consistent UI.
That’s what I was personally missing so I see no reason to go C#. Bought myself a book just to see and my conclusion (a bit rude I admit) is C# is basically the same language with classes renamed and a different compiler.
And yes, if you ask, I also refuse to use C# on a daily basis _because_ it is made my Microsoft and I am ready to make some efforts with java if everything is not perfect from the start just because of that. Java is getting better all the time as is C#. Maybe I am quasi-religious on this as some previous poster said, but sometimes some beliefs can be useful. I also use linux for ideological reasons until some other open source os can bring me all the tools without the hassle. I could as well use pirated windows software at home, it would be pretty much easier but I don’t.
Well anyway, I am just a fucking communist afer all…
— my 2 Eurocents.
Correct me if I’m wrong, this is just an open specification for UNIX CLI’s, but has nothing to do with the support libraries. All this allows is a skeleton of a .NET program to run on a non-Windows platform.
right, it’s an implementation of the runtime.
and a nice sample app: a javascript compiler written in c#.
To the php vs asp dispute many years ago.
Of course php was opensource and developer friendly.
Sun should realize that its days are counted,
both Microsoft and Linux are a long term threat,
and they’ll probably end up like SGI if they
dont fight Microsoft on an even field.
That is, they should push the java technology as open
standard and opensource, and also make the language
more coder friendly, like microsoft does.
(and they should start by adding enums back
1) .NET is not compiled (usually), just as Java is not compiled (usually). Both execute bytecode on a virtual machine. And no, a bytecode VM and an interpreter are not the same thing.
2) The performance differential becomes even greater when you factor in the fact that J2EE is the fastest Java VM (for most things) while Mono is actually faster than Roter (Microsoft’s VM).
3) Ease of development with .NET is supposedly even better than with Java. Neither language itself is particularly great in terms of development time. In terms of the language itself, they are both just cut-down, tweeked versions of C++ with a few improvements afforded by the VM. The real advantage to these languages is the giant class libraries, which are apprantly better on the .NET side.
4) Before anyone makes a comment along the lines of C#/Java will replace C/C++, I’d like to offer my theory. I think both languages will be relegated to specific roles in the custom programming, server applications market, where speed of development and ease of maintenence is key (and where the class libraries help big time). In the system programming realm (meaning the apps desktop users use day to day) C/C# will rule thanks to the new wave of open source C/C++ libraries out there. Both Java and C# were designed (largely) to solve problem with C/C++ libraries: binary compatibility in the face of closed source applications and libraries. It’s always been a weakness (especially in the case of C++) that small changes to libraries could break binary compatibility. In the face of advances in compiler technology, as well as the growing power of Open Source, the importance of binary compatibility will become less, and C++ programmers can start really taking advantage of the wealth of libraries out there.
On the flip-side, programs that need really quick development will be written in *real* high-level languages like Perl and Python. These languages have features in the language itself that make application development quicker. And thanks to the new Parrot VM (from the Perl6 project) these languages will also have good performance, thanks to a fast underlying VM.
> Btw: Isn’t the managed code extension closed source, I
> am fairly certain that it hasn’t been ISO’ed.
Closed source, yes, like the rest of DirectX.
By “ISO’ed”, are you referring to ISO standardization? C# and the CLI will be by the end of the year. http://www.oetrends.com/cgi-bin/page_display.cgi?108
DirectX most likely won’t be as it’s Windows-specific.
> “Cross platform for .NET is coming…”
> Ehm… NO! – I’ll wager my house that my homemade .NET
> program using WinForms and System.Data.SqlClient won’t
> work on mono. (I know they’ll be trying to create a
> wrapper around it…)
We’ll see when Mono v1.0 comes. As long as your homemade .NET program isn’t making PInvoke (native platform) calls, I don’t see any valid reasons here why it won’t happen. I think the Mono people have an easier task ahead of them than the Samba project did, but they managed okay.
When is your game library going to be cross platform?
> Cross platform CLI is comming – NOT .NET, there is a
> HUGE difference!
Yes, and apparently you haven’t figured it out. Mono is more than the CLI; they are also including a C# compiler, a full class library, etc. A lot of the class library is for compatibility with MS .NET, but they also have class libs for supporting Bonobo, GTK, etc.
Cross platform does not have to mean lowest common denominator. With .NET you can have compatibility across different OSes and physical architectures, while being able to leverage a specific platform’s strengths at the same time. For example, developers coding on .NET for Linux will be able to write apps specifically for Gnome, being able to use native widgets and specific features Gnome offers. If desired, they could also write up a WinForms front-end as part of the same app and simply determine at install time (or even at app startup) which front end the user needs/wants to use.
J2EE is not a VM. It’s a collection of classes and APIs. Stupid fuck-wit. Learn technology before spouting off.
> 1) .NET is not compiled (usually), just as Java is not
> compiled (usually). Both execute bytecode on a virtual
> machine. And no, a bytecode VM and an interpreter are
> not the same thing.
sigh… .NET code is ALWAYS compiled before it executes. First call to a function, the function is JITed and that COMPILED code is then executed. Every time the code runs, it is running as native code.
I second the “Learn technology before spouting off” motion.
For those of you who have no knowledge of J2EE, I can inform you that these tests where made without using common sense. Everyone with IQ > their shoesize designs J2EE applications without so-called Entity Beans, and I really mean *everyone*. Why this was not the case here, can I only speculate in – but a link at Microsoft to the test results maybe gives a clue…?
J2EE apps designed using common sense (i.e., Stateless Sessionbeans instead of Entity Beans, use of JDO:s, etc.) perfoms equally to servlets-only implementations – and servlets-only is *fast* (precompiled & cached).
Move along folks, nothing to see here (just some FUD, but you’ve seen that before, haven’t you?)
mauerj:
“[managed extension] Closed source, yes, like the rest of DirectX”
So if my program uses managed extensions it’ll be b0rked – even on Mono – which leads me to:
“We’ll see when Mono v1.0 comes. As long as your homemade .NET program isn’t making PInvoke (native platform) calls, I don’t see any valid reasons here why it won’t happen.”
Which you effectively counter argued yourself, since managed extensions aren’t available on other platforms than Windows.
“Yes, and apparently you haven’t figured it out. Mono is more than the CLI;”
And you apparently haven’t been using .NET …
Try looking at the System.Data.SqlClient – this is a SqlServer 7.0 Specific class – how on earth do you expect the Mono project to make this class???? – and if they do, at the same performance…
What about all the other Windows specific components in .NET? – they can only hope to mimic tham, but I’ll bet that most of it won’t even come close to the windows specific parts, such as ADO and ASP.
“When is your game library going to be cross platform?”
When it’s done… We’re working on getting the win32 version done first (since thats 95% of the target audience) and then add Mac OS X support and then Linux. The process of making it crossplatform is rather simple, since we use OpenGL and OpenAL which are already crossplatform.
“Cross platform does not have to mean lowest common denominator…<snip> … while being able to leverage a specific platform’s strengths at the same time. <snip>… simply determine at install time (or even at app startup) which front end the user needs/wants to use.”
Same with Java – Classloader and JNI – no biggie.
for the true successor to C(and C++)!
Get rid of pointers, unnecessary syntax(aka semicolons), get strings included and stop adding every features known to man…
RPG and COBOL is a brease compared to PC languages. How do companies, using PC languages based programs, stay productive without breaking their budgets?
>>Try looking at the System.Data.SqlClient – this is a SqlServer 7.0 Specific class – how on earth do you expect the Mono project to make this class???? <<
They wouldn’t, the would make the System.Data.OleDb “namespace” (not class, it’s a collection of classes) which is not database specific.
Wow, I mean, just wow. Not only was .NET remarkably faster, it was amazing that they could not get App Server B to function and stay stable. It’s unfortunate that they can’t tell us who that app servers are. I’m sure App Server vendor A wishes they didn’t have that nagging clause in their license agreement.
Brutal.
One statistic really tells it all I think.
That being that 2000 vs 14000(?) lines of code. Really powerful statistic. But even more interesting is that it shows how much of the application was actually done within the .NET core itself, and not the application. Once in the core, there is a lot of room for native libraries and code to take over to help boost performance.
That also means less maintenance by the coders, and ideally faster development time.
Regarding .NET, yes, it is ALWAYS compiled. The key distinction between .NET and Java is that .NET is NOT an interpreter, it is a compiler. The byte codes of .NET were never designed to be interpreted, always compiled. Also, unlike Java, once .NET is compiled, it remains compiled. It’s compiled and cached on load, versus JITted in place like Java is. Different approach, which should lead to faster start up times, and the ability to stablize faster as well. Many of the Java JIT compilers do not JIT everything they see, but rather, everything that’s popular, so the code image takes some time to settle down once it’s reastarted, and it must do this every time.
Regarding Entity Beans, the reason folks are using entity beans is because that’s what the vendors are pushing. They all make a big deal about entity beans. One such vendor basically asserts that their entity beans talk the exact same SQL as an equivalent Stateless bean. The key may be the definition of “equivalance”. Perhaps most Stateless beans don’t do the same things that an Entity bean does.
Plus, an Entity bean with BMP is the ONLY way (I know of) to cache data USING EJBs. (You can always do something outside of EJBs, of course).
Regarding “NT can’t scale to big machine like Java/Unix can”, that may be true on a single instance case, but if you can get similar functionality from clustering smaller boxes, for less money, then that is a non-issue. Simple case here is that the app server licenses cost as much as W2K and the hardware, so for the same cost, you can get twice the hardware running the .NET solution. But I don’t know if .NET can cluster that way.
As far as this being put on by a crowd of Microsoft cronies, I’m skeptical of that. These guys make a lot of money off of Java. Minimally, however, the ball is in the App Server vendors court to come up with a comparable J2EE solution that can perform better than this .NET solution, and as well documented. I think that will be very difficult. Foul can be called high and low, but most of the data needed to really replicate this system seems to be published here.
The biggest, blackest mark against this is the fact that .NET is a single vendor, single platform solution right now, and the fact that the single platform it runs on is Windows. A lot of people don’t have much faith in Windows for demonstrable reasons.
But, as show by this benchmark, bang for the buck (cheaper software, cheaper development, cheaper tuning, and more performance), it’s a pretty compelling platform.
I don’t myself running to it any time soon, but I think this report is going to stir things up quite a bit.
http://www.python.org
Did anyone notice that they used different databases for J2EE and .NET?
Despite all the noise that have been created with this rather controversial report, the results are still inconclusive in regards to the actual performance advantages of J2EE vs. .NET because the comparison is still unfair and skewed more in favor .NET rather than J2EE. Those folks compared apples to peanuts if you understand the archtecture of the Pet Shop application and its implementation on .NET vs. J2EE. The Pet Shop application is basically a tutorial app that was design to showcase all core technologies included in the J2EE spec and definitely not to be an all encompassing benchmark test. J2EE implementation of Pet Shop makes a heavy use of Entity Enterprise Java Beans — stateful transaction-aware objects that are persisted to RDBMS, use of which was totally inappropriate for this kind of application — this is exactly where the .NET performance advantage comes in. .NET doesn’t have a direct equivalent Entity Beans and thus the .NET implementation of the Pet Shop has much simpler (read faster) implementation of the middle tier. I’m pretty sure if the same application was implemented without the use Entity Beans or EJB’s at all, the perfomance gap would close or J2EE would even surpass .NET in performance. In many cases EJB’s are used in places where they shouldn’t be used and I’ve seen drastic improvements in performance when EJB’s were dropped in favor of simple DAO’s.
Plus, three points that caught my attention:
1. As you all know, publishing perfomance statistics for .Net is illegal without an explicit permission from M$, so obviously the Middleware folks obtained a permission from M$ and thus had a close contact with Redmond. This information is conviniently omitted from the report, which makes me think that M$ had some sort of involvment in that study and/or indirectly sponsored it.
2. Implementation of the database tier is conviniently omitted, which makes me question the fairness of the comparison one more time.
3. The report says that some sort of performance tuning was performed on the systems, but to what extend and what parameters were used to improve the performance. Was it really tuning or detuning, I can’t tell.
So, to all of you .Net trolls, may be it’s too early to celebrate and draw too far-fetched conclusions.
1) You’re right, J2EE isn’t a VM. I was referring to the Hotspot VM used in the tests. Since this VM is bundled with Sun’s J2EE server, I didn’t think the distinction was important. You were not only rude, but rude over a nitpick! So sad…
2) Just because .NET is a JIT’ed language doesn’t make it a compiled language. There is still the overhead of the initial JIT-ing, as well as the performance loss from the necessity to use less time-intensive optimization algorithms. Sun’s Hotspot VM does the same JIT compilation, except it uses more fine-grained compilation units.
“RPG and COBOL is a brease compared to PC languages. How do companies, using PC languages based programs, stay productive without breaking their budgets?”
Sounds like you want Fujitsu NetCOBOL for .NET (also available on Linux)…
http://www.adtools.com/
Let the market decide the outcome of this. Personally, I don’t think either platform is going away any time soon, and of course I think .NET is going to make great headway against Java.
So what’s the problem? If you like Java and are in a position to use it, go for it. If you prefer .NET, like I do, and are in a position to use it, like I am, there you go.
I think it’s fun to argue and discuss these things, but the bottom line is that the market is going to decide which platform has more mojo. I can’t predict which one it will be. Even if Microsoft has a vastly superior product (as in this case), many people will choose another product simply because it’s not from Microsoft. And they may think they have compelling reasons for doing so, although I think most of those reasons don’t stand up to careful scrutiny.
Even if Microsoft has a vastly superior product (as in this case), many people will choose another product simply because it’s not from Microsoft. And they may think they have compelling reasons for doing so, although I think most of those reasons don’t stand up to careful scrutiny.
You are right that many companies won’t use .NET because it’s from Microsoft. That sentence doesn’t mean “because it’s from microsoft, the tech is bad”. No, what I meant by it is “because it’s from microsoft, we’ll end up with our balls (or bollocks, if you’re in Britain) in the vice.”
Even if Java results slower in non-MS sponsored benchmarks (is that even possible? I mean, that there could exist any non-MS sponsored benchmarks?) by a large margin, business independence is such a strategic asset that most companies will stay with Java. As I said, MS is going to reap what it seeded all along. And please, spare me the gratuituous “Microsoft is not evil”. You know, if it smells like sh*t and it looks like sh*t, you might just as well call it sh*t.
But maybe I am completely wrong, and IBM, HP, Ericsson, Nokia, CA, etc. will all adopt .NET :-)))))))
“They wouldn’t, the would make the System.Data.OleDb “namespace” (not class, it’s a collection of classes) which is not database specific. ”
Uhm Heellooo ?
If the System.Data.SqlClient isn’t available, my program will b0rk. This is *exactly* why .NET implementations on non windows platforms will fail miserably, if they claim that they will allow full “crossplatformness” of the entire .NET framework. It just won’t work!
However, that said there are many libraries in the .NET framework that are eligible for crossplatform implementations…
It’s funny though, I just don’t get why they placed the SqlClient in the System.Data name space… I mean, they use Microsoft.* for their specific stuff – should have placed it in Microsoft.SqlServer.SqlClient… Oh well I guess thats why it’s only the CLR/IL that has/is being standardized, and not the framework…
Mario
“(little preface: You can run java on big iron. Say, 16 CPUs with lots of disks via fiberchannel (or is it fibre channel?). In that configuration, java would beat .NET, because .NET doesn’t support the platform.)”
Well if that isn’t the dumbest thing I’ve read all day. Sort of like saying a trailer tractor rig will always beat an Indycar when you use diesel. Face it, how many small/medium businesses, the real battleground for .Net/Java, are going to want or afford to run big iron in preference to a server cluster?
“But at the end of the day, .NET is useless for most comanies that are currently Java shops. The reason is strategic: these companies just don’t want to get in bed with Microsoft more than they have to.
That’s not to say there won’t be companies that will adopt .NET, but I am sure that most won’t, and not because of technical reasons. MS is going to reap what it had seeded for many years.”
Bet you anything you like once they see results like the one in the article that all these Java shops will abandon their precious anti-MS principles faster than Oprah abandons a new diet.
“Mark my words, flame if you want but mark my words and check back in 2 years from now.”
Thanks for the invitation to flame. The real question is, where will we find you in two years time
Rayiner
“.NET is not compiled (usually), just as Java is not compiled (usually). Both execute bytecode on a virtual machine. And no, a bytecode VM and an interpreter are not the same thing.”
.Net is compiled. Always.
“The performance differential becomes even greater when you factor in the fact that J2EE is the fastest Java VM (for most things) while Mono is actually faster than Roter (Microsoft’s VM).”
Not really much for Sun to boast about is it when you consider that the MS VM development has been locked down (read abandoned) for years now, thanks to Sun’s whining.
“Ease of development with .NET is supposedly even better than with Java. Neither language itself is particularly great in terms of development time. In terms of the language itself, they are both just cut-down, tweeked versions of C++ with a few improvements afforded by the VM. The real advantage to these languages is the giant class libraries, which are apprantly better on the .NET side.”
Erm .Net is not a language, it’s a framework that encompasses many languages. That’s what makes it so easy to develop in, because you can use existing skills and knowledge in languages like C++, VB, Python or Perl. For that matter COBOL is implemented, so even the beards can code in .Net.
J2EE implementation of Pet Shop makes a heavy use of Entity Enterprise Java Beans — stateful transaction-aware objects that are persisted to RDBMS, use of which was totally inappropriate for this kind of application
Of course they were used. They’re one of the core technologies of the J2EE server. And the vendors continue to promote their use. What kind of application SHOULD Entity Beans be used for?
I’m pretty sure if the same application was implemented without the use Entity Beans or EJB’s at all, the perfomance gap would close or J2EE would even surpass .NET in performance.
Yes, I can guarantee that if you dump the EJBs, and thus remove J2EE, all of the overhead of a J2EE server would be removed.
So, if nothing else, this is a story about how bad EJBs are. If you get rid of (most) of the beans, then about all that you have left in the EJB server is a transaction monitor. Ok…
1. As you all know, publishing perfomance statistics for .Net is illegal without an explicit permission from M$, so obviously the Middleware folks obtained a permission from M$ and thus had a close contact with Redmond. This information is conviniently omitted from the report, which makes me think that M$ had some sort of involvment in that study and/or indirectly sponsored it.
I’ve always liked the clause in license agreements. Isn’t the remedy for breach simply termination of the license? So, why not get a NEW license then AFTER you’ve published.
It was mentioned that a MS employee was there tuning the .NET tier. He put two weeks into it.
The point here, though, is that the ball is back in the J2EE court to come up with an application that has comparable performance here. If the EJBs are getting in the way, then why use the J2EE server in the first place. If they’re offering more functionality than is being used, giving .NET a “free ride”, then why not restructure the application to more heavily rely on the features of the EJBs and thereby punish .NET.
It seems to me here that a company that has pretty good visibility in the J2EE space, run by Noted Authors of J2EE books and practices, and implemented as a guide to How Things Should Be Done, came up with a system that appears DRAMATICALLY slower than the .NET solution, may have took longer to write (simply based on line count), and cost much more money to be deployed.
The goal was to create an “equal” application, and on THAT criteria, .NET stomped J2EE.
What I would have liked to have seen is how the numbers from the “untuned” servers differed from the tuned versions after 5 weeks of tuning. How much more performance did they squeeze out of the system after tuning. 10%? 200%? It would be interesting to know, because in many systems, it is very difficult to “tune” a system to get another 100% of performance, save on the SQL side with some really horrid queries that go from 20 minutes to 10 seconds. And the queries involved in this kind of system seem pretty straight forward.
Getting that kind of leap in performance is usually an algorithm change.
>> The goal was to create an “equal” application, and on THAT criteria, .NET stomped J2EE.
That’s the point, it is not even possible to create truly equal implementations of Pet Shop in .NET and J2EE since there is no alternative to Entity EJB’s in .NET. The only way the application implementation can be on comparatively equal footing is when persistance to database is handled either through Session EJB’s only without any involvement of Entity EJB’s or through DAO’s without any EJB’s of any type.
>> So, if nothing else, this is a story about how bad EJBs are.
No, this story is about how not to use EJB’s in wrong places and definitely not how bad EJB’s are. EJB is a stellar technology for use in transaction-oriented environments where it stands head and shoulders above the competition. It just may not be very appropriate to use EJB for bread-and-butter web applications.
And by the way, J2EE is much more than just EJB.
The real advantage to these languages is the giant class libraries, which are apprantly better on the .NET side
Sorry, but i doubt this remark… Java has tons of APIs available… almost for everything…
J2EE implementation of Pet Shop makes a heavy use of Entity Enterprise Java Beans — stateful transaction-aware objects that are persisted to RDBMS, use of which was totally inappropriate for this kind of application
Of course they were used. They’re one of the core technologies of the J2EE server. And the vendors continue to promote their use. What kind of application SHOULD Entity Beans be used for?
The Pet Shop project is native J2EE and is used to elucidate the use of J2EE features…
After making a .NET version of it, they testers should have done a feature list and redo the Pet Shop project for J2EE from scratch, using EXACTLY the same features as the .NET version.
Preferibly, the testes would be made in similar iron with similar benchmarks for the rest of the elements… that would mean, similar calc speed, similar database benchmarks, similar data thrughpout thru all the other application components. THE ONLY diferense should have been the PeT Shop Application by itself, in it’s two new incarnations.
That would be as i would “try” (double enfasis on try, because i don’t qualify myself with enought knowledge of both platforms to do it) do to such a benchmark…
Other then that it is just something that doesn’t deserve the paper it’s printed on… or the space it fills in the computers…
Cheers…
You’re right, J2EE isn’t a VM.
Translation: I was wrong.
this VM is bundled with Sun’s J2EE server
Translation: I equate “J2EE” with Sun’s J2EE implementation, despite the fact that many other vendors release J2EE servers. I will then proceed to refer to every piece of java software released by Sun as “J2EE”.
I didn’t think the distinction was important.
Translation: I don’t think it’s important to be accurate.
You were not only rude, but rude over a nitpick!
Translation: I can’t believe you care about accuracy! I should be able to spread incorrect information and get away with it.
Just because .NET is a JIT’ed language doesn’t make it a compiled language.
Translation: I’ll ignore the fact that I said .NET uses a VM (when it doesn’t)
Rayiner, what you said was wrong.
You might possibly know what you’re talking about, but you certainly aren’t showing it.
“J2EE is the fastest Java VM” is completely wrong.
As is “Both execute bytecode on a virtual machine”
“ tweeked versions of C++ with a few improvements afforded by the VM” – I’m not even going to touch that one…
I was wrong
>>>>>
I foobarred calling Hotspot J2EE, yes. Still doesn’t change the actual point of the sentence.
Sun’s J2EE is the only one + All Java stuff = J2EE
>>>>>>>>>>>>>>>>
I’d really like to see how you derived this. Seriously. That’s one hell of a leap.
Distinction is important
>>>>>>>
No, the distinction isn’t important. My point was that the Hotspot VM (used in this test) was the fastest Java VM. Instead of writing Hotspot, I goofed and wrote J2EE. You made a very rude comment and a big arguement over a meaningless quible over words.
.NET doesn’t use a VM
>>>>>>>>>>>>>>
What do you call the CLR? From Microsoft’s FAQ, the CLR:
– Loads and converts MSIL into machine code.
– Provides type safety and memory protection.
– Garbage collects objects.
That’s exactly what the Hotspot VM does. Now, you can get into what VM actually means, and argue that the CLR isn’t one because it doesn’t execute MSIL directly. At that point, you have to argue that Hotspot isn’t a VM either, because it JIT compiles the Java Bytecode. The only distinction you can draw is the time at which this bytecode is translated. Rotor translates the code at module load time, while Hotspot uses a dynamic/fine-grained approach. But that’s an implementation detail, and calling one a VM and the other not, just because of that difference is a strech. The semantics of the terminology aside, the .NET CLR is commonly referred to as the .NET VM. Just read the Mono design docs or any of the number of articles about .NET. The whole VM issue aside, you again miss the point while arguing petty details. People said that .NET should be faster because it is compiled while Java is interpreted. .NET is most certainly not compiled (in the common usage of the word) and Java certainly isn’t interpreted
(in the common usage of the word). Technically, they are very close together, and neither has an inherent performance advantage.
And both C# and Java *are* just cut down versions of C++ with certain features afforded by the VM. In terms of syntax, they are all very similar and offer similar language features. Java lacks multiple-inheritence and templates, while it gains introspection, object-level protection, garbage collection, and synchronized methods. Most the stuff that makes Java, Java, is in the class libraries. This includes threading, dynamic class loading, etc. Similar functionality (for the most part, aside from introspection) can be accessed in C++ from libraries just as naturally (synactically) as in Java. It’s just that the standard set of C++ libraries is nowhere near as integrated and full featured as the standard Java libraries.
The other distinction about something being a VM or not is the intent of the design. Java is certainly designed to be a Virutal Machine, and has been from the beginning. It was intended to be embedded in other devices and to provide a stable environment for bytecode execution. The Java bytecodes are the “machine language” of the Java VM. This is one reason why you can find Java on everything from small embedded applications to mainframes. I can guarantee you that on those small devices, the Java bytecodes are interepreted directly, and not JIT compiled at all. Those machines simply don’t have the room or horsepower for it.
With .NET, this is not a fundamental of the design. .NETs code is a an “intermediate language”. The similiar example to .NET is the backend language that the GNU compilers convert all of their languages into. This is not designed to be interpreted, it is designed as an intermediate step between source code and object code.
With a .NET binary, you technically have a binary image that’s not quite done yet and still needs further processing to be executed. This is the final “compile” phase that creates object code. The final intermediate code is compiled, cached, linked and run on the fly by the .NET runtime engine. While no doubt a system could be written to interpret this intermediate language, I’m not aware of a system that actually does. As far as I know, every system uses the intermediate language precisely for that.
This is important because the intermediate language CAN (I don’t know that it actually does) contain extra information that is used to generate better code than what the Java bytecodes can convey.
When you write a compiler for bytecodes to a VM, you want that information to be as efficient as practical for your interpreter, knowing that your interpreter is going to be iterating across these codes continually. Whereas with an intermediate language, you can be more verbose and include much more context information that my be helpful is making more efficient object code knowing full well that anything that is unncessesary will be tossed out during the compile phase before execution. With .NET, they can even make the initial compile more expensive because of the fact that they only compile the code once, then cache it, whereas the Java JITs do it every time.
The important detail here is that any context information that can be provided, and later discarded, by an intermediate code has to be inferred by the a JIT engine. It must look at the code behaviour and analyze it on the fly to determine potential optimizations, where an intermediate language can convey that information from the actual original language source.
So these are very important distinctions done at the outset. Java was designed to be portable and have an efficient, interpreted bytecode, whereas .NET was designed to get several languages converted into an intermediate form that can then be compiled on the final platform. Both can end up as a portable environment, however I think that a minimal the .NET platform is a little more heavy weight than a minimal Java platform.
The fact that Java has JIT compilers is a detail of implementation. Not all VMs have these compilers, as they’re not necessary for the specification. With .NET these compilers are not a detail, but the actual intent of the entire system.
http://dreambean.com/petstore.html
Ops another M$ nice non trustworthy move?
Firs of all is this OSnews or is it MSprogrammingNEws?
Anyway any real world implementations of .NET that actually scale AS well as sun boxes in real life.?
doubtful.
This is news for LAN people.
As everybody knows by now, MS’s business practices are based on LCS (lie, cheat and steal). But this is too much even for them.
I guess the monkey and Billy-the-McCarty are quite pissed off with Java’s success and .NET’s un-adoption rate. Even John Caroll is not very efficient as a FUD generator on ZD I guess.
Todays news about these “benchmark” is, it appears like The Middleware Company (The idiots related with these “benchmarks”) was sold to a firm called Precise in this August.
http://austin.bizjournals.com/austin/stories/2002/08/05/story3.html
Precise is a software company which has strategic partnership with MS (No Sun, no BEA, no IBM etc connection.):
http://www.precise.com/Partners/Strategic/index.cfm/FuseAction/Deta…
For intelligent people, here is the link containing an article refuting these benchmark from a very famous name, Rickard Öberg:
http://dreambean.com/petstore.html
He is also started a new project, developing a proper Pet Store here:
http://sourceforge.net/projects/petsoar
Yet another Pet Store implementation written by a single developer (Not by “J2EE experts” company), which contains equal code with the .NET implementation (Not 12.000 lines more), written in couple of weeks (Not in 4 months) in a much much better way here:
http://www.ibatis.com/
Please read the discussions on the server side related with this idiocy to see the reactions of intelligent people.
IT started to resemble more and more to “the young and the restless” because of MS.
Conclusion:
Who Lost:
The middleware company, “the J2EE experts”, lost their credibility by creating idiotic “apples to apples” “benchmark”.
Sun, Java, IBM, etc got hit.
Poor sites like OSNews are also got damaged by putting links to these idiotic “benchmarks” as if they are something important.
MS further lost their already non-existing credibility.
Who Won:
John Caroll liked it probably, as he already spilled out every possible FUD on his ZDNet articles, and probably was looking for a new FUD source.
These will come back much faster now:
Error Performing Query
* [State=37000][Error=170][Microsoft][ODBC SQL Server Driver][SQL Server]Line 1: Incorrect syntax near ‘=’.
* [State=37000][Error=156][Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near the keyword ‘else’.
* [State=37000][Error=156][Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near the keyword ‘else’.
* [State=37000][Error=156][Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near the keyword ‘and’.
* [State=37000][Error=156][Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near the keyword ‘else’.
* [State=37000][Error=156][Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near the keyword ‘as’.
* [State=37000][Error=156][Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near the keyword ‘as’.
* [State=37000][Error=156][Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near the keyword ‘AND’.
* [State=37000][Error=156][Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near