Back to newsletter 043 contents

First of all, if you have a J2EE application performance management (APM) solution that you want to have included in my upcoming review, contact me ASAP. I'll be looking at all segments of performance management over several articles, so don't miss out on being referenced.

Next, those of you who may be interested in meeting me, or winning a free copy of my Java Performance Tuning book should pop on over to the Application Performance page where you can register to attend my talk in London or Reading (UK) next month. I'll be delighted to meet anyone who can attend.

We are also delighted like to announce the availability of public Java performance tuning training courses. Our first courses are being arranged for Toronto, Stockholm, and Frankfurt. Please contact us about your interest in any of these courses.

A note from this newsletter's sponsor

In the newsletter we list our usual raft of articles, news, and more. In the news, yet another Java vs C++ benchmark generated a lot of heat, this time with the C++'ers deperately crying foul as Java seems to outperform. Our opinion here at JavaPerformanceTuning.com is that such benchmarks are essentially useless: Java is fast enough for anything you might want to do, and is much more productive than any other significant language.

And in the articles, JavaWorld is definitely back: they produced some good articles listed last month, and an even better one is listed this month. In addition, we have most of our usual sections. Kirk's roundup covers some interesting discussions; Javva The Hutt comes back with his latest diary entry, bemoaning his inability to wangle a JavaOne trip; And our question of the month asks What memory to measure when you are monitoring the JVM.

This month our article is a tool report, showing what DevStream's JView J2EE performance monitoring tool can do. We also have a new cartoon, and many new performance tips extracted in concise form.

A note from this newsletter's sponsor

News

Java performance tuning related news.

• Java vs C++ benchmark (updated)
• Kirk's analysis of the (lack of) usefulness of the Java vs C++ benchmark
• The slashdot fallout. This has got to be the funniest Java vs C++ discussion I've seen. The C++ lovers are desperately crying "unfair, we have to manage memory manually and you don't". Their suggestion to even up the score - add in lots of calls to System.gc() to slow down Java (in case you don't realize, Java does reclaim the memory without calls to System.gc, adding calls to System.gc just slows down how it does so). Further complaints all seemed to boil down to this being a benchmark biased to Java. But strangely enough it wasn't 3 years ago when the test against the then JVM version showed C++ faster. Probably some valid comments somewhere if you really dug amongst the drivel.
• Yet more discussion. Someone could have made a lot of money from all the hot air (or superfluous characters) generated over this brouhaha.
• A survey of garbage collection in Java & .NET
• Heroix eQ Management Suite lets you monitor performance according to specific business processes.
• WebSphere aims to reduce hardware requirements by automatically optimizing workload sharing
• Java3D source code is being released. The resulting slahsdot discussion includes performance considerations, but I don't know why I continue to list slashdot discussions here because there is just so much noise in there compared to the very few items of useful info.
• First SPEC jAppServer2004 results (from IBM)
• Good discussion about the usefulness of multithreading, especially for perception as opposed to raw number crunching
• Useful performance test showing the effects of different factors including application level processing, Java network I/O and OS I/O.
• TeamStudio profilers spin off to form Enerjy Software
• Java 1.5 seems 20% faster
• OpenDemand load tester in the news.

A note from this newsletter's sponsor

Tools

• DiagnoSys J2EE monitor
• Asynchronous IO for Java replaces java.io and java.nio functionality but is intended to be more scalable
• Method Scheduler for Java (MS4J) is a robust scheduler component that allows developers to execute methods on Java objects asynchronously and/or repeatedly.
• Implementation of the Core J2EE Patterns - Value List Handler
• Toolkit for Reliable Multicast Communication

Books

• Java Testing and Design, From Unit Testing to Automated Web Tests (Prentice Hall), Frank Cohen

Recent Articles

• Developing a performance strategy (H&W/H&W)
• Defining and Building High-Performance Software (Adam Neat/STPmag)
• Improve XML transport performance, Part 1 (Dennis M. Sosnoski/IBM)
• Improve XML transport performance, Part 2 (Dennis M. Sosnoski/IBM)
• Connection Pools for JDBC (Alexey Prohorenko and Alexander Prohorenko/devX)
• Understanding Tuning TCP (Deepak Kakadia/Prentice Hall)
• Message acknowledgment and redelivery with message-driven beans (Simon Brown/java.net)
• Clustering and Load Balancing in Tomcat 5, Part 1 (Srini Penchikala/OnJava)
• J2EE application performance optimization (Rahul Kuchhal/JavaWorld)
• Fixing the Java Memory Model, Part 1 (Brian Goetz/IBM)
• Fixing the Java Memory Model, Part 2 (Brian Goetz/IBM)

Jack Shirazi

Back to newsletter 043 contents