Re: RFC: JVM Registry
> First: certain programs not running with certain JVMs. This can be
> addressed a lot quicker by simply having those packages either Conflicts:
> with that JVM package...
Not true. You can have several JVMs installed at once; having BadJVM
installed doesn't stop me from using FunkyApp with GoodJVM which is also
installed.
> ..., or by having the package detect (in a pre- or
> postinstall script; I'd prefer pre-) the offending JVM package is
> installed, and making the user ack this problem. A question like:
>
> jpython has detected you have $JVM installed. This is known to not
> work with our package. Do you want to install anyway? [Y/N]
Same deal; if anything you want to tell the admin that they want another
JVM in addition, and offer details on how to make it the default. Note
also that RandomUser on DepartmentMachine will never see this message, and
the sysadmin may or may not have other reasons for keeping /usr/bin/java
pointing to BadJVM.
> Except in fairly aberrant cases, which JVM you use *should* be
> transparent.
This differs from app to app. The blackdown port offers better
compliance to sun specs (and better adherence to sun bugs). The kaffe
JVM is free and so allows a Java app to go in main/ if it's supported.
And given that it differs from app to app but the /usr/bin/java link is a
global decision, one wants to be able to get details about individual
JVMs, hence the registry proposal.
> Do we really want to put in such a heavyweight process
> as this proposed registry just because right now you occasionally need
> to know what JVM might be running your program? I'm working on packaging
> javabayes, which misbehaves drastically with kaffe, but I'm not going to
> do much more than drop a README in the doc directory, because I want
> kaffe to fix their bugs, rather than code a painful workaround.
Which would not be at all painful if such a registry were in place. There
will always be problems with different JVMs, some of which are bugs to fix
and some of which are problems that are very long term (eg. "we at the
fooJVM team won't be implementing classes in java.crappy.api because we'd
rather concentrate on better things).
And meanwhile - and this includes during periods like the woody release -
we want the apps to behave cleanly for the users as well (see DFSG) rather
than just use the breakage as leverage to motivate upstream JVM authors.
> As far as requiring a specific runtime version, we can currently handle
> that with appropriate virtual packages. I agree with whoever it was who
> suggested obsoleting java-virtual-machine in favour of
> java1-virtual-machine. If we have to get so far as to say
> java1.1-virtual-machine, sure it's annoying, but I don't think this
> registry is the right answer.
But how does the java app startup script know *which* installed JVM is the
one that provides their particular version?
For your approach to work you'd also need alternatives /usr/bin/java1.1,
/usr/bin/java1.2, etc, and your 1.3 JVM would have to offer itself as an
alternative for all symlinks of lesser or equal version. This way the app
that needs (say) 1.2 support can get it by running /usr/bin/java1.2. I
think this is at least as messy a situation as the proposed registry.
> I'd much rather investigate other
> alternatives that might be useful to more people, like versioning virtual
> packages.
Agreed, that would be useful for dependencies, but you still have to
decide what to do at runtime.
> > 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).
>
> What's wrong with requiring jikes's packaging to handle this? If it's
> invoked as 'javac', it should have all the default classpaths set up,
> and if not, then you should know what you're doing. :)
So your suggestion is to change the semantics for empty classpath to mean
"no core classes are provided, and the bootstrap classpath will be
automagically determined (in which case the Version: tag is not
necessary).
Note also that jikes will still need proposed registry to automagically
determine a bootstrap classpath as you suggest it does; there is currently
no way for it to determine a bootstrap classpath right now short of
hard-coding the classpath for each packaged JVM into the jikes startup
script, which is the sort of mess this proposed registry is aiming to get
away from.
Ben, who is afraid to go near a television set just now.
Reply to: