A current project under Ubuntu 10.04 has me pondering the proper way to satisfy the Java dependencies of an installable package that requires a JVM and officially supports only Sun's JVM, but appears to run just fine with Ubuntu's default OpenJDK 6 JVM. The question is then: How should one define the package's dependencies so that Sun's JVM is the preferred JVM, but the user still has the flexibility to use OpenJDK, albeit with a warning that what he's doing has no official support? And after some research, apparently, it can be done.
I haven't figured out all the details yet, but here's what I've gleaned so far.
There are two current options for a JVM under Ubuntu 10.04:
and if your package has an absolute, non-negotiable requirement for one or the other, then you're pretty much done here. But if your package is prepared to be flexible, there's more you can do.
If you example the properties of those packages, you'll notice that both of them "provide" the functionality of a generic "java6-sdk" so if your package had no preference whatsoever, it need only specify a dependency of "java6-sdk" and you're good. But sometimes it's more complicated than that.
According to Florian Diesch on the Ubuntu users mailing list, you can specify a dependency of:
sun-java6-sdk | java6-sdk
Apparently, what the above means is that either of those choices will satisfy your package's installation dependency, but if neither exists on your system, the first choice ("sun-java6-sdk") will be installed, which is sort of what you want -- that either JVM is acceptable but, given a choice, you'll opt to install Sun's JVM.
Still, that may not be quite what you want because, in a perfect world, you might want to allow the user to use the alternative JVM only with a suitable warning that what they're doing has no official support. And, apparently, you can do that, too. But first, a side note.
It's entirely possible to have two (or more) JVMs installed on your system, and you can see this with the command:
$ update-java-alternatives -l java-6-openjdk 1061 /usr/lib/jvm/java-6-openjdk java-6-sun 63 /usr/lib/jvm/java-6-sun $
Obviously, on my system, I have both JVMs but I can only be running one and I can tell which one that is with:
$ java -version java version "1.6.0_18" OpenJDK Runtime Environment (IcedTea6 1.8) (6b18-1.8-0ubuntu1) OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode)
Obviously, I'm currently invoking the OpenJDK JVM.
If I want to "switch", I need only:
$ sudo update-java-alternatives -s java-6-sun update-alternatives: error: no alternatives for mozilla-javaplugin.so. update-alternatives: error: no alternatives for xulrunner-1.9-javaplugin.so. update-alternatives: error: no alternatives for mozilla-javaplugin.so. update-alternatives: error: no alternatives for xulrunner-1.9-javaplugin.so. $ java -version java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) $
Clearly, I'm now using Sun's JVM. And why does this matter?
It matters because, however you define your package's installation dependencies, the fact that you have merely installed a particular JVM doesn't mean that you're actually using it. It means, in a nutshell, that besides defining your package's JVM dependencies, you will probably have to invoke
update-java-alternatives as part of the install process to make sure you're running the JVM of your choice. Which leads us into ...
This is the part I'm still working on but, apparently, you can use Debian's "debconf" utility to do exactly what we're describing here. To get started:
$ sudo apt-get install debconf-doc $ man 7 debconf-devel
and that's as far as I've got here, but it seems clear that this will allow me to do exactly what I want -- prefer Sun's JVM but still allow the user the freedom to override that preference while generating a warning that makes it clear what he's doing has no official support.
And if working with OpenJDK goes badly wrong, the user can always just switch back to Sun's JVM and continue working. More details as I figure them out.
We're aware of the time and budget pressures at most companies, normally accompanied by the plaintive cry from management of, "Yes, I know we need training on that topic, but I just can't afford to send my entire team away for three (or four or five) days to get it!" And that's where we come in.
The main focus at Crashcourse is to offer a choice of intense, 1-day, hands-on courses on specific topics in Linux and open source. And given that we already have the laptops for the delivery of that training, the idea is to show up early, set up a classroom, then spend the day teaching exactly the topic you're interested in. No travel time, and no wasted classroom time.
If we don't already have a course that addresses the topic you're interested in, drop us a note and we'll see what we can do -- our content providers can almost certainly put together a course that's precisely what you're after.
While there are a variety of sources for Linux and open source training, we at Crashcourse are taking a slightly different approach. Our philosophy is simple: exactly the training you want, and no wasted time or travel to get it.