Skip to main content

The OpenJDK mistery (probably) solved

Posted by fabriziogiudici on August 6, 2008 at 2:47 PM PDT

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:

  1. 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.
  2. Tweak the startup script so the proper JDK is choosen:

OPENJDK_JRE_HOME=/usr/lib/jvm/java-6-openjdk/jre
SUN_JRE_HOME=/usr/lib/jvm/java-6-sun/jre
SUN_JRE32_HOME=/usr/lib/jvm/ia32-java-6-sun/jre

if grep -q Ubuntu /etc/issue
    then
        UBUNTU=true
    else
        UBUNTU=false
    fi

# 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
    export JRE_HOME=$OPENJDK_JRE_HOME
else
# 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
                export AWT_TOOLKIT=MToolkit
                ;;
      *x86_64*) export JRE_HOME=$SUN_JRE32_HOME
                export AWT_TOOLKIT=XToolkit
                ;;
    esac
fi

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:

Comments

Debian (in unstable), OpenSuse (11 & factory), Gentoo (in an overlay both open6 & open7) - and an increasing number of smaller distributions.

Yes, it can be just Ubuntu's fault. But with better tagging, I would have immediately understood that it was a different OpenJDK. BTW, what are the distros that are shipping OpenJDK out-of-the-box or in the default update center, other than Fedora and Ubuntu?

it is just crazy that you even can't expect from two bundles, containing the same jdk build having the same bugs fixed. The version string looses its meaning if it doesn't represent the version... If there is something like a "patch level" than please add it (if it is really necessary but it seems so) to the version string and list the bug fixes per patch instead of per build. (but maybe its just the ubuntu bundle's fault - it was one of the first bundles) It is already hard enough because fixes are integrated more ore less randomly to openjdk6/7 or the sun jdk. >BTW, is there any OpenJDK page where a single table sums up the situation for every distribution?... +1, that is really what we need. (than I can remove half of my bookmarks ;) )

"You have to make different packages for Fedora and Ubuntu because Fedora uses the RPM and Ubuntu uses the dpkg packaging format, regardless of your Java runtime choice." Yes of course, but my hope was to do only two packages, while this situation seems to be diversified for a larger number of distros. "I'm sure the ubuntu java team would welcome your participation, you are a very good writer." Thank you, I actually would like to help. "The other issue that your story exposes is that distributions need to work on better documentation for Java developers... " BTW, is there any OpenJDK page where a single table sums up the situation for every distribution? It would be useful to have a single page where developers can look and find what is exactly the OpenJDK release that is available on each system and the TCK status, plus a link to the pages of the specific distribution for further information.

You have to make different packages for Fedora and Ubuntu because Fedora uses the RPM and Ubuntu uses the dpkg packaging format, regardless of your Java runtime choice.

Anyway, the core of your issue is that distributions don't run on the same clock - Canonical's Ubuntu Hardy branched & released a couple of weeks before Fedora 9 in last May, so it lacks fixes for issues exposed by Red Hat running the TCK that made it into Fedora 9 in the meantime.

As I said before, there is a proposed update for Ubuntu Hardy that should contain those fixes - it has not passed the TCK yet, though. You may want to try it anyway by adding the hardy-proposed repository, it would be a much better idea then trying to use alien to run the fedora package.

The other issue that your story exposes is that distributions need to work on better documentation for Java developers that are coming new to Linux and packaging to make sure they understand how it all works, and fits together, and how they can create packages that meet their and their users' expectations on top of OpenJDK and/or other rutimes.

I'm sure the ubuntu java team would welcome your participation, you are a very good writer.