Re: RFC: JVM Registry
On Tue, Sep 11, 2001 at 02:35:41PM -0500, Ben Burton wrote:
>
> (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).
That is true. Is there a way to "Depend: java-virtual-machine (>= 1.3)" ?
This seems to be a workaround for the lack of that possibility...
> - 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.
But acording to the policy the binary that sets up the virtual machine must
give the correct classpath for its environment.
But of course there are problems with setting up the classpath like for
example jikes.
> - 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.
Is juthon a command line tool? If so it should provide a command line tool
that have the correct init lines. But maybe I'm starting to get the point.
You want to create a registry to help the program to get information about
what is installed.
> 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
Hmm...
> 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.
But to me it still looks like you want to propose some virtual 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.)
That is ok but I'm not still convinced.
> 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).
Yes but the main problem is that some of the virtual machines just
do not provide everything and so in some cases you have to add extra
things to the classpath. Swing for example is provided by j2sdk1.3 but
have to be added manually for all other jvm:s.
> 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
Agreed! :)
> 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?
Some more thoughts:
As I can see there is a big disadvantage with this. It is not enough... :(
There are still some issues that are insane... All the java libraries provided
by different packages, like xalan, bsf, fop, xerces, xt and more. If you
are about to use them you have to manually include them. There can also
be version conflicts... And the thoughest thing is that you do not just
have to know what it depends on, you also have to know what jvm:s that package
depends on, and so on.
So I want to generalize your repository (or what you want to call it) to
include all packages that provides or depends on some sort of jar files.
That can be done in a lot of ways... The problem is that it can exist
circular dependencies. So a couple of simple shellscripts that calls
each other is probably not enough.
This are my thoughts. It is a good idéa but to get rid of a lot of the
java issues we have today we need some more things. I'll think about it
and maybe I can figure something out this weekend. :)
Regards,
// Ola
> Ben.
>
>
> --
> To UNSUBSCRIBE, email to debian-java-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
--------------------- Ola Lundqvist ---------------------------
/ opal@debian.org Björnkärrsgatan 5 A.11 \
| opal@lysator.liu.se 584 36 LINKÖPING |
| +46 (0)13-17 69 83 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
Reply to: