RFC: JVM Registry

[Ben Burton <bburton@mail.math.okstate.edu>]

(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.