Re: RFC: JVM Registry
On Fri, Sep 14, 2001 at 04:45:42PM -0500, Ben Burton wrote:
>
> 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.
That sounds good. I think I'm a bit more on the end-user-side but still
on the side end-developer-side. :)
> > > - 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.
Maybe we should force the existance of a java-1.3 symlink in the bin
dir? Don't get me wrong. I just want to have a simpler somlution than
a registry, but still more general.
> > > - 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).
Ok. I see.
> > > - 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.
I was not really clear on this point. I ment that you were proposing
the mechanism similar 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.
Now I can see the difference in out viewpoint. You have good knowledge
in what classes that are provided by each virtual machine. I do not have
that knowledge (or at least not that good), so I have to look it up
from time to time. What I want is a mechanism so that I do not need
that knowledge. :)
> > 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).
That sounds like the perfect way of doing this. As I understand it
there are some problems.
1) You do not know if you got the right jvm.
2) The jvm does not always add the right CLASSPATH for itself.
That is a bug though.
3) Even if you include the jars that you know, they can depend on other
jars that you have to find out (can be quite hard).
4) More?
> 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.
Exactly.
> > 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)
Nothing. That is a perfect way of doing it. The thing is that I want
to use that information to set the correct classpath. :)
> Perhaps I'm missing something here; could you please give a (hypothetical
> is okay) example of how using debian depends would fail?
Well they do not fail, but they are not enough to set the correct
classpath. :(
Take this example (hypothetical) that I have faced sometimes with
the java library (and servlet) packages that I maintain.
We have four packages.
Package: foo
Type: servlet, library or command-line tool.
Depends: bar
Package: bar
Type: library package only
Depends: gaz (always)
Package: gaz
Type: library package only
Depends: goo (sometimes in some special cases)
Package: goo
Type: library package only
So we want to set the correct classpath for foo. In the documentation for
foo we can see that it depends on bar. Bar is packaged in a special way,
normally the jar file also contains gaz, but becuase of some issues
(like dependency problems or other) it has been split into two archives.
So the maintainer adds bar.jar into the classpath. He (or she) test it
and finds out that ... ohh gaz.jar should be added too. This is what
I want to avoid.
Ok it works but we can have one more case (not as obvious). We now have
CLASSPATH=bar.jar:gaz.jar
But in some rare cases that foo triggers in some important function that
foo needs. Because foo does not depend on goo (to compile, but to run
in some cases) directly it can be very difficult for the user or maintainer
to find it out.
So we are talking about different things I think. You are focused on the
virtual machine and I focus on the packages (on a quite high level) that
depends on a LOT other jar archives.
There are a number of ways to fix this but this is
On compile time a script can be generated for each jar-archive that
provides a proper classpath on the information it gets from the
"Depends:"-line.
* Problems:
- One package can provide a number of jar archives (which can conflict
with each other). Xalan2 is a example of this. It provides both
xalan1 and xalan2 compatible jars, even if the xalan1 one is not
always perfectly backwards compatible.
- If the dependency information ("below" the package) changes the
package have to be recompiled. So you have to have a tool that
gets this information on run-time.
* Sultion:
+ As I proposed on some other message each java-library package should
"Provide:" all jars it contains. So you only have to depend on the
jar file name.
+ Have a tool that fixes this information on run-time and not on
compile time.
> 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.
Maybe we should have a standard location for them. :) Symlinks are just
fine to me.
> Hmm, I'll think some more.
Me too. :)
What I can see we have two major problems:
1) Tools that needs to have a bootstrap classpath, like jikes.
2) The problem of jars that depends on other jars that are not
obvious on compile-time.
I want to have a (or maybe two but not too different) mechanism that
fixes both issues.
I'll think some more. But it should be solvable if we just
standardize it some (and get rid of that damn /usr/share/java/repository
directory). :)
Regards,
// Ola
--
--------------------- 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: