One of the reasons I like Java is that the virtual machine allows you to forget about the underlying hardware/OS most of the time and focus on solving your business problems. And I have almost become complacement about a steady release of new versions of Java, generally faster, with new features and fewer bugs – and all for free!
Last week, however, we had a reminder that this does not always work according to plan. A customer updgraded their boxes from Java 1.5 to Java 1.6 and performance collapsed. Not just a little bit, but by a huge margin. We ran their tests on our Windows box and they were absolutely right – what took 1 second on Java 1.5 was now taking 17 seconds. It was the same code, same input PDF, same hardware – all that was changed was the JVM.
Intrigued, we ran the tests under a profiler and traced the issue to a single cause – the PDF we were handling was accessing the CMM colour function to handle an ICCColorspace. It appears that Sun has altered the underlying library used the JVM to handle this and for our usage, it has much poorer performance.
Happily, we were able to rewrite the code to avoid this (so our test now takes less than a second on both Java 1.5 and Java 1.6). But the reminder for us, is that while Java may offer a virtual machine, its performance can still vary widely between versions. So it still makes sense to optimise even a virtual language towards a specific target platform and version if performance is important.
Do you need to write or read JPEG in Java?
We have an easy guide on how to write JPEG in Java using ImageIO and JDeli.
You can learn how to read/write most of the image files in ImageIO. However, it gives little control over the process.
JDeli is easy to use and offers complete support, so why don't you give a try?