Re: RFC: JVM Registry
Just a couple of notes; I'll think about this over the weekend too.
The first thing I should say is that this registry is *not* primarily
intended for end users; it's mostly provided to aid startup scripts for
other packages; to allow them to be friendlier and to break under fewer
system configurations.
> > - 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)" ?
Not right now, but even if it were possible, there's no guarantee that
/usr/bin/java points to the 1.3 JVM as opposed to some other 1.1 JVM.
Using package dependencies is not enough here; hence the proposed registry
with a script to launch a JVM of version >= foo.
> > - 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.
I'm not talking binaries that start Java apps; I'm talking binaries that
refer to core Java classes for other reasons, such as Jikes (which refers
to them during compilation).
> > - 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.
Yep, you're right. Jython is a command-line tool, and the registry would
be queried by the jython startup script itself so it can behave properly
from the viewpoint of the end user.
> But to me it still looks like you want to propose some virtual packages.
The only virtual packages I have proposed were java2-*, which were on a
different thread. The Package: field in the registry file would refer
to the actual debian package that contains the JVM/compiler.
> 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.
So once again the registry is your friend. Your swing-app startup script
queries it to see if the JVM it's calling is 1.3 or less; if it's less, it
addes the swing classes to the classpath and if not it doesn't. The
registry actively helps get around this problem.
> 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.
The way I've got jython working is this: The jython startup script takes
everything the user wants on the classpath from $CLASSPATH. To that it
adds the libraries jython requires (such as servlet-2.2.jar). This
larger $CLASSPATH is passed to the JVM, which in turn should add its own
bootstrap classes. Thus everything works. If you want more details, try
installing the jython package and look at /usr/bin/jython (ignore the use
of whichjava; this is what the registry would hopefully replace).
The point being that the packager of an individual Java app should know
what dependencies that app has, can put them in the debian Depends: and
include them on the classpath in the app's startup script, as described
above.
> 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.
What's wrong with using debian depends for this? As far as individual
(non-core) libraries go you can get away without virtual packages; eg:
Depends: libservlet2.2-java (>= foo), lib-editline-java (>= bar)
Perhaps I'm missing something here; could you please give a (hypothetical
is okay) example of how using debian depends would fail?
The big difference I see is that the core classes come from virtual
packages java-virtual-machine, etc. and are not provided in any standard
sort of location, whereas 3rd party libraries come from real packages and
are provided in /usr/share/java/package-name.jar.
Hmm, I'll think some more.
Ben.
Reply to: