Java 6 speed

Java 6 was released last week (or was it two weeks ago) to, in my view, surprisingly little fanfare. It may be the circles I travel in now, but it just wasn’t seen as that big of a deal with most people I know, nor with many tech sites I visit. From what I can tell, the big news tends to be the performance increases. There seem to be some other interesting bits – a committee spec from 3 years ago has made its way in to this release which will make it easier for ‘scripting’ languages (dynamic/loosely-typed) such as PHP and Python to more easily integrate with Java (or at least the JVM itself). It’ll be neat to see how that plays out, but I think it’ll be a while (certainly months) before we see anything usable for production systems in the mainstream consciousness (and that would be aggressive!).

Perhaps the most interesting thing to me was/is the performance angle. It’s an easy thing to point to, and is easy for people to digest, and makes a good reason to upgrade. Sun is promoting this angle on their site here, with quotes like:

“When the early builds of Java SE 6 came out, we jumped in to see if we could get any performance improvements, which are crucial to our business. To make a long story short, the difference between Java SE 5 and Java SE 6 was startling. In terms of crunching through air fares, we are talking an increase in speed of 25% to 30%.”

I know I’m being overly cynical here, and all major vendors do this, but doesn’t this mean that earlier Java versions were that much slower? I realize systems continue to get optimized, new techniques are employed, etc., but my goodness – 30%?!? For years – even *recently* – when I’d say Java is slow, hardcore Java people would point out the latest hotspot JIT compiling work, improvements in Java5, etc. Java 6 just seems to confirm what I’ve felt and known for years – Java, on the whole, is slow. If they’ve found ways to wring out another 30% performance (and I bet some apps will see even higher improvements), how much more could have been done? It’s all a balancing act, and some improvements get shoved down in the name of backwards compatibility and stability and all that, certainly I know this. I’m still just a bit flabbergasted, all in all, that there was this much room to be had.

I do think the open sourcing (next year, finally!) will lead to some long term improvements in the ability for people to improve Java performance, optimizing it for their particular needs to an even greater degree than is done now.

On a related note, this link was sent to me. It’s great to see a major vendor have open forums where people can report bugs and have some transparency on the process. But the last poster’s comments do seem to hit home – why should people have to ‘vote’ on something as basic as 64-bit support in 2006?


I spoke to a Sun engineer at the local JUG last night, and he indicated that the Java 6 SE provides better speed not from compiling (as in javac) but from better run time optimizations – mostly compiling things to machine code at run time. From what I gathered, this had been done before, but the Java 6 improvements are largely related to a much more granular method for selecting which sections of code to convert to machine code. Because it can be more selective, there’s less to compile, meaning less overhead of ‘compiling during runtime’, meaning faster performance.  I am posting this here to take a bit of the cynical edge off the entire post.  Certainly there will be more improvement in the future – most large scale projects like this will have improvements over time.  I’m hoping that the open sourcing (done by next summer) provides more people the opportunity to contribute more optimizations and speed improvements.

I'm currently working on a book for web freelancers, covering everything you need to know to get started or just get better. Want to stay updated? Sign up for my mailing list to get updates when the book is ready to be released!

Web Developer Freelancing Handbook

Leave a Reply