(btw, I have switched on a television since I wrote the following email;
my thoughts are with everyone in the US and others connected to the
incident.)
As it stands, a machine may have many JVMs installed, all of which
provide no information via package management other than provides:
java-virtual-machine. This leads to the following problems:
- A Java app may need runtime version >= foo but currently has no way of
knowing if such a runtime is installed, or even if it is then whether
/usr/bin/java points to such a runtime, and if not then where to find
such a runtime (note that the output of java --version is not
consistent across JVMs).
- Another app may need to know where the core Java classes are. There is
currently no way for anyone to know this other than to have a
hard-coded list of classpaths for each JVM available for debian (this
is what the whichjava script tried to address, but I want to replace
that with this new proposal). An example here is jikes which needs to
be given the bootstrap classpath from another installed JVM.
- A Java app may for whatever reason need to know which particular JVM is
being called by (say) /usr/bin/java. An example here is jython which
doesn't work with ORP; rather than spew out indecipherable error
messages, one wants the startup script for jython to detect that orp is
being used and display a polite message explaining the problem and
advising how to request a different JVM.
So. What I propose is to create a JVM registry. This will be in a
directory (say /usr/share/java/registry or /etc/java/registry). Each
package that provides: java-virtual-machine will be required to place a
file in that directory (preferably named the same as the package to avoid
clashes). The file will look similar to a debian control file; for
example:
Runtime: kaffe
Package: kaffe
Exec: /usr/bin/kaffe
Classpath:
/usr/share/kaffe/Klasses.jar:/usr/share/kaffe/comm.jar:/usr/share/kaffe/microsoft.jar:/usr/share/kaffe/pjava.jar:/usr/share/kaffe/rmi.jar:/usr/share/kaffe/tools.jar
Version: 1.1
Fields being:
Runtime: a token identifying the particular JVM
Package: the debian package providing this JVM
Exec: a path to the binary that starts this JVM (this is the
destination that /usr/bin/java would point to if this alternative were
being used)
Classpath: classpath representing the core Java classes
Version: approximate JDK version for this JVM
The reason for having both Runtime: and Package: is that, for instance,
package j2re1.3 might have:
Runtime: blackdown
Package: j2re1.3
and package j2sdk1.3 might have:
Runtime: blackdown
Package: j2sdk1.3
That is, they use the same JVM even though they come from different
packages.
Following this, package java-common would provide:
- The registry directory itself (eg. /usr/share/java/registry);
- A set of scripts that query the registry (eg. find a JVM with version
>= foo, find the Runtime: token corresponding to /usr/bin/java, find
the classpath for the given JVM or for /usr/bin/java, find the JVM
with greatest version, etc.)
On top of this we could also have a similar registry for compilers;
perhaps using the same directory but with Compiler: tokens instead of
Runtime:. For instance:
Compiler: blackdown
Package: j2sdk1.3
Exec: /usr/lib/j2sdk1.3/bin/javac
Classpath:
/usr/lib/j2re1.3/lib/rt.jar:/usr/lib/j2re1.3/lib/i18n.jar:/usr/lib/j2re1.3/lib/javaplugin.jar:/usr/lib/j2re1.3/lib/sunrsasign.jar
Version: 1.3
Another example:
Compiler: jikes
Package: jikes
Exec: /usr/bin/jikes
Classpath:
Here an empty classpath indicates that no core classes are provided, and
that a bootstrap classpath needs to be provided on the command line (in
which case the Version: tag is not necessary).
Finally one would put in java policy that packages that provide
java-virtual-machine and java-compiler are required to install such
registry files.
As for java-virtual-machine-dummy and java-compiler-dummy, perhaps these
registry files could be conffiles or links to conffiles that the user
edits to reflect the non-debian JVM/compiler they have installed?
Anyway. I really do want some kind of scheme in place to turn this large
insanity into a lesser insanity. The findjava and subsequent whichjava
scripts were designed to address these same problems, but somehow a registry
seems to be the best solution since each JVM package maintainer can keep
their own JVM details up to date, and no JVM will be inadvertently left
out of the list (as is a problem with the findjava/whichjava scripts
posted earlier).
Thoughts?
Ben.
