$)CLies, Damned Lies, Statistics (and Benchmarks!) (First, please support Javalobby by clicking here to order Rational!/s FREE PowerPack CD for Java developers. It!/s amazing but true, simply clicking this link will help pay for Javalobby to continue to be free and strong. Thanks in advance!)
The old line "lies, damned lies and statistics" needs to be amended to include "benchmarks" at the end to signify that benchmarks have an even lower status and credibility factor than statistics. The Java community is abuzz with anger, indignation and confusion regarding the latest round of Pet Store benchmarks comparing Java!/s performance with that of the monopolist!/s .NET framework. The Middleware Company (TMC), owners of the popular TheServerSide.com J2EE website, recently released a performance comparison between .NET and Java based on a newly optimized version of Sun!/s Java Pet Store reference application. Java did not do especially well in this comparison with .NET, but it is unclear whether the Pet Store application TMC used was representative of Java!/s best or even whether the benchmark comparison is relevant at all? Personally, I am weary of hearing about this Pet Store issue, and I regret discussing it here except that it so inflamed the Javalobby membership and the Java community as a whole. In short, it is clear that there were some problems in the process that TMC used, and it is clear that some of the choices TMC made give the appearance of impropriety. I say the appearance of impropriety because I don!/t think anything nefarious has actually happened. TMC has been widely accused of selling out because they allowed Microsoft to commission the comparison and to pay for the creation of an optimized Java Pet Store application to put up against the .NET version. I have no reason to believe TMC did anything worse than make a foolish choice in allowing Microsoft to fund this benchmark application development. I have been acquainted with Ed and Floyd at TheServerSide for a long time, and these are really good guys who have always seemed to have their Java priorities in the right place. Such a flagrant "sell-out" as they have been accused of would be totally incongruous with my experience of them. Still, it was naive, at best, for them to take the monopolist!/s money to pay for the benchmark and report. It also seems probable that TMC could have worked harder to ensure that the Java application they developed was truly optimal. Now it looks like they are getting ready to make the same mistakes again by allowing Microsoft to fund a rematch maybe they are gluttons for punishment. Don!/t do it, Ed! The many flaws and problems with the TMC implementations have been discussed in depth at Javalobby and elsewhere, so I won!/t go into them much here. One key issue has to do with the use of EJB!/s on the J2EE side (with no corresponding entities on the .NET side) that simplify development but incur a performance hit. Another key item is the questionable choice of starting with Sun!/s original reference application, a teaching tool, and attempting to modify it for performance. The Sun application was never intended to be a dragster, it was created to help people learn to understand and use some valuable J2EE features. Of course, there are other problems, but these two alone seem to stack the deck against J2EE from the start. People are afraid that their managers will hear that .NET is faster than Java and will mandate the use of .NET based on that fact, so I!/d like to suggest some ways to respond if this starts happening to you. It would be great to discuss this openly at Javalobby so we can combine our best efforts into a distilled, high-potency set of talking points that every Java and J2EE advocate will benefit from keeping handy. I!/ve started a discussion on the subject, and you can click here to join it, I really hope you will. First, it doesn!/t matter much if one platform is three times as fast as it needs to be and another is five times as fast as it needs to be. Either way, the platform is still abundantly faster than it needs to be to get the job done. This reminds me of people arguing that you should buy the car that can go 175 miles per hour instead of the one that can only go 140 miles per hour. It doesn!/t matter, folks, you can!/t legally drive that fast, and you!/re probably running other serious risks if you do! Second, it is not so impressive that the monopolist has managed to eke raw speed out of their thin veneer of interfaces on top of the underlying Windows operating system. It would even be alarming if they didn!/t! The performance they achieve, however, comes at the direct expense of the portability that brings freedom and choices to all of us who use Java. It!/s just like Henry Ford!/s famous comment about the Model T, "You can have any color you want, as long as it!/s black." You can run a .NET application on any platform you want to, as long as it!/s Windows. I know they call a lot of attention to the Mono project, but I am not holding my breath until that is ready to play hardball in this league. Third, anyone who adopts .NET is taking a giant leap into bed with one of the most assiduously committed monopolists in history. I have read lots of complaints lately about the increasing costs of licensing software from Redmond, and the writing is on the wall about which direction the pricing will be going if you use .NET in the heart of your enterprise. These performance numbers make look promising today, but wait until three years from now when you!/re irrevocably locked in and Redmond raises the licensing costs for the fifth time. You!/ll be having a hard time making the return-on-investment arguments hold water then, but J2EE will still be open and competitive. Java will continue to offer both performance and freedom of choice. These are just a few points to get the ball rolling. Let!/s see whether we can do something effective and collective by working together to formulate a really hard-hitting list of talking points in response to this PR debacle that TMC and TheServerSide have started. If we can forge some unity on the Java side, then the outcome won!/t be nearly as bad as the numbers look at first glance. Join us in the discussion now, and let!/s get organized in our response! Until next time, Rick Ross [EMAIL PROTECTED] --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
