Which Job Hunting Tips Are Right for You?
Leverage Business Continuity as a Revenue Generator
Demand Grows for API Specialists1
What to Do When You Don’t Know the Answer1
People Moves: Information Transport Solutions, RingCentral, Zumbox1
Developing Cloud-Based SaaS Web Applications1
How to Pick a Hackathon1
NSA Revelations: Has The Planet Gone Mad?10
NextGen Seeks Both Techs and Recruiters1
Feds Closing Data Centers Find 3,000 Additional Ones1
Let’s compare Java and C#, two programming languages with large numbers of ardent fans and equally virulent detractors. Despite all the buzzing online (“I’m about to rant. Who else hates working in C#?” one blog might complain, even as another insists: “Java ruined my life.”), it’s hard…
Copyright © 1990 - 2013 Dice. All rights reserved. Use of this site is subject to certain Terms and Conditions
Excellent article. I love how methodical it was. It surprised me that the Java http communication was so sluggish.
Just a few thoughts about my original expectation. I thought this might delve into the whole idea of the development process and how it affects the end results. From my experience, C#.NET is typically easier to develop in than Java, although that’s just because the .NET environment seems to have better features that tools like Eclipse play catch-up (although this could easily change at any time). In addition, since the libraries are customized in .NET for Windows, I think that once you get in the Windows mindset, it’s easier to find things than in the more generic Java libraries which appeal to people on different platforms with different ways of thinking about projects.
Finally, although I feel that C# development tends to be quicker, Java is, of course, much more transportable so you can develop in whatever environment lets you feel comfortable, then deploy on practically any other environment.
So both have their benefits and drawbacks; I’ve grown accustomed to C# development, but would jump back to Java if asked to work on things like portable (aka phone) apps because of the broader market appeal.
Having just worked in both C# and Java I think the difference is that C# has their web UI game a bit better nailed as far as variable binding and general flow. In the java side there was that terrible time with backing beans then came seam and now JSF. And not a lot of people are so happy with JSF. Things are moving to stronger javascript frameworks on the front end. But java has much stronger development on the back end especially database patterns and integration, threading, etc. These were developed back when the JCP worked. We don’t know now how the new stuff will come out. Java is also cleaner in terms of APIs something that IS a result of the JCP and feedback, and something that Microsoft will blunder more severely with , like linq for entities 3.5 which was just about unusable.
This article walks through two micro benchmarks of very narrow library functionality. I wouldn’t use this type of test to evaluate JVM/CLR.
IMO, .NET is successful for companies that want more full stack single vendor Microsoft solutions and want to integrate with products like SharePoint and want to minimize custom development. Java excels at more custom software, more flexible stacks. The Java ecosystem of libraries and technologies is much more vibrant and diverse but on the downside it is more chaotic.
JSF has a horrible reputation in the Java world. If I were doing a dynamic JavaScript web application, I would keep the UI fully client-side JavaScript and the server would be strictly
web services on the server with no server-side HTML templating system (this goes for a .NET as well). If I was really doing a web site where server-side HTML templating made sense, I would use the Play Framework and I would probably use Scala.
Working as Consultant in a Microsoft Partner, I find myself primarily working with C# and the .Net Framework, though I have used Java in the past. I love that you took the time to perform these tests, and I think you performed a very thorough assessment of the technologies. Your intent, to help Architects and Developers pick the best tool, was a great goal, and I think that’s the right mindset to have. It’s not a Microsoft vs. Sun approach, it’s about meeting client needs and doing it with the tool that makes sense for them, and (as a consultant) is supportable when you leave. Thank you for this great article.
That being said. I think you missed one thing: The inherent page caching capability in Tomcat which must be enabled in IIS in order to operate. I understand you were operating in a relatively “Vanilla” environment, but this makes a huge difference on 2 fronts.
1. Is it important that the DateTime.Now() operation on each pages shows a distinct value? (I would wager the responses were not unique to the millisecond on the Tomcat run). I think this would be a core requirement for this “client”.
2. In my opinion, the tests may not have been equal, because essentially, IIS/.Net was doing all the work every time, and Tomcat/JVM wasn’t.
I would be interested to see what would happen if you enabled output cache in IIS 8, or disabled it in Tomcat and reran the tests. Not because I want to see .Net kick the pants off of Java per se (I don’t know that the results would even change), but because I would like to see an even playing field.
Thank you again for taking the time to run these simulations and post the results.
I love the image of this article about performance. It indicates a SQL string inside some business logic. Dynamic SQL passed to the DB from your BOs is not your friend in terms of optimized performance.
Just saying