The OpenJDK mistery (probably) solved
If you have read comments to my previous posts, you should have understood what happened. For people not reading them, I'm posting a recap. For details, please refer to previous posts.
In a few words, I've discovered that running my application with OpenJDK on Ubuntu I get a blocking issue, that doesn't appear with Sun JDK. I was somewhat puzzled by the fact that the bug was reported on the OpenJDK issue tracker and marked as closed; so I supposed was a similar bug not previously found and not solved yet. I also inferred that it was a test case slipped off the Test Compatibility Kit. It seemed the only logical explanation of the fact.
On the contrary I was wrong in assuming that OpenJDK 6b9 on Fedora is the same thing as OpenJDK 6b9 on Ubuntu. While I wasn't able to grab a Fedora installation disk and try by myself, Massimiliano Aroffo from JUG Milan and Federico Pedemonte from JUG Genova were so kind to test it for me, and proved that the bug doesn't appear on Fedora. Mark Wielaard explained me that just looking at the 1.6.0-b9 version string doesn't guarantee that two OpenJDK packages are the same bits, as they can differ in the patch level. It turns out that Fedora's OpenJDK has passed the TCK, Ubuntu's is instead an older copy.
So OpenJDK is ok and the TCK has a good coverage; it's the package actually present on Ubuntu that is broken.
This of course is quite annoying. With Sun's JDK, putting a dependency on it in your package guarantees that your application will run against the same Java bits that you've tested with (and every missing piece is downloaded and installed on the fly). At the moment, this assumption is not true with OpenJDK. This is a serious issue IMO since for any broken installation users will blame either you, or Java, or both. This is not good for the Java technology, and I think that it must be addressed as soon as possible by adding the proper tags to OpenJDK packages, in a way that you can put a safe dependency on them.
In the meantime, what you can do? Right now, I must be sure that blueMarine runs with Sun's JDK on Ubuntu and OpenJDK on Fedora, and that its installation will automatically download the required stuff. An option could be to prepare two different packages, one for Fedora and another for Ubuntu, but I find it crazy to have a WORA technology and be forced to make different packages for different distributions of the same operating system running on the same hardware! Looks like the Linux fragmentation hell is striking us hard.
So what I've done is the following:
- Replace the 'openjdk-6-jre' dependency in the .deb package with 'java6-runtime'. This is a 'virtual package' that is satisfied by any of the existing Java 6 implementations around. In other words, the installer will be satisfied if either OpenJDK or Sun Java 6 are installed on the system. What happens when there's no Java 6 on the system is a problem that I'm explaining below.
- Tweak the startup script so the proper JDK is choosen:
if grep -q Ubuntu /etc/issue
# If OpenJDK is available and it's not Ubuntu, use it (OpenJDK is broken on Ubuntu)
if [ -d $OPENJDK_JRE_HOME -a $UBUNTU = "false" ]; then
# On 32-bit Linuxes, just use regular JRE-6-sun and MToolkit to fix Compiz incompatibilities.
# On 64-bit Linuxes, be sure to use a 32-bit VM and XToolkit or a bug will happen.
# See http://bluemarine.tidalwave.it/issues/browse/BM-605
/> case "`uname -m`" in
*i686*) export JRE_HOME=$SUN_JRE_HOME
*x86_64*) export JRE_HOME=$SUN_JRE32_HOME
The problem is that I can't control what happens in the case that no Java 6 is installed on the system. Which one will be downloaded, Sun's or OpenJDK? Either the application manager will choose by itself, or will ask the user to choose. But I can't assume that the user is able to make the correct selection, so in the end it might happen that the installer will download the wrong JDK and the startup script will fail. Asking the user to take care of it is very bad: multiple times people have stated that, for Java to be successful on the desktop, users mustn't be tampered with technical stuff. Things must just work with a few clicks, as it happens with other technologies.
It's clear that I don't like this extra complexity (as I don't like the additional complexity in the startup script), so I hope this is only a temporary workaround until the OpenJDK mess is fixed.
What do you think?
PS The next part is about performance. My preliminary tests show an extreme slowness of OpenJDK-on-Ubuntu when compared to Sun Java-on-Ubuntu, but it could be another consequence of the old bits packaged in. After I run the test with the correct version, I'll let you know.
Technorati Tags: OpenJDK