I am pleased to announce that the J2SE 5.0 release has gone final and is ready for you to download! The first set of downloads for Windows, Solaris, and Linux are available from the http://java.sun.com/j2se/5.0 Web site. This even includes a 64-bit AMD64 port on Linux for server-side applications. Other OS support and tools will follow from our partners, so please let them know that you are waiting for a particular port.

I was fortunate to be able to fly to New York for the J2SE 5.0 launch and give a short presentation, called "5 reasons to move to 5," to the New York SIG. I checked the flight deals on Orbitz (which runs J2SE on Linux), sent my expense request using a Java Web Start-enabled expense tool, and I was ready to go.

While I was waiting for the plane to take off, I paged through the in-flight magazine and came across the section describing the type of aircraft I was currently seated on. It proudly noted that the engine for this 757 flight was a Rolls Royce. I've never actually been in a Rolls Royce car, which is now part of the BMW group; however, the name Rolls Royce for me is a byline for reliability and performance. I think their messaging worked; I knew they wouldn't really put any old engine on a plane but I felt more assured that a Rolls Royce engine would have exceeded any certification test they threw at it and was more than capable of getting me to my destination.

Fast forward to the New York SIG. As Yakov writes in his editorial this month, Java is used heavily on Wall Street. I knew Java was behind many of the popular consumer Web sites but the Java platform is the Rolls Royce engine for Wall Street and provides not just the horsepower, but the integration solution too. The good news is that the J2SE 5.0 release is the most rock-solid, stable platform we have ever tested.

The testing criteria is raised for each release and our testing experts and TCK specification test writers have done an impressive job. At the same time we have added more features, made it faster to start up and also smaller to download. That may be a pleasant surprise for many of you - improving start up time was the number one request I received and we made good on that promise. There were several contributing factors but the lion's share of that improvement came from the new Class Data Sharing technology.

With the subsequent volume in press activity, I've received many e-mails from developers who perhaps haven't looked at Java for a while and want to know what the advantages of 5.0 are and should they switch? If you count yourself as one of those developers and have a question or comment, send me an e-mail, I will be happy to help.

To continue with the Tiger theme, we have two great J2SE 5.0 articles this month. The first is a comprehensive look at the new enumerated type keyword, developed through JSR 201. The second is an article describing the monitoring and management framework as developed through JSRs 163 and 174. This is just the start of some great J2SE 5.0 content we have lined up, so make sure you pick up next month's magazine too!

To close, I just wanted to share another new 5.0 feature with you. The feature in question is the new StringBuilder class, also known as the unsynchronized StringBuffer. At first glance you may feel that synchronization generally means slower and therefore you should retrofit this new API in your codebase to see dramatic speed improvements. Hold on though; if you have only a single thread accessing your StringBuffer in the first place (the conditions that StringBuilder requires), the monitor lock itself is fairly cheap. Monitors only start to get expensive when more than one thread needs access to that protected code block. The first thread just tests and sets a bit and proceeds. It's only if another thread passes through that same piece of code at the same time that things change. The next thread detects the bit is set and creates a monitor queue to hold any other threads that need to wait. This is the more expensive operation and is called monitor inflation. In my own tests with a single thread that never required monitor inflation I needed to run at least 10,000 StringBuffer operations to see a savings. As in all performance tweaks, I would recommend running your own benchmarks to see what savings you can achieve.