Re: RFC: JVM Registry
On Tue, Sep 11, 2001 at 02:35:41PM -0500, Ben Burton wrote:
> So. What I propose is to create a JVM registry.
Alarm bells start going off when I hear "registry". Not knee-jerk
"registries much suck 'coz M$ does 'em", but bells nonetheless. This
seems like way too heavy-duty a solution for the problem.
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, 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]
Would be an acceptable first approximation, to my mind. Sure, there
are problems with it (what if they have multiple JVMs?), but they're
not that difficult to deal with (so, tell it to go ahead).
Except in fairly aberrant cases, which JVM you use *should* be
transparent. 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.
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. I'd much rather investigate other
alternatives that might be useful to more people, like versioning virtual
packages.
> 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:
<snip>
> 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).
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. :)
> Thoughts?
I appreciate the effort you went to to think this through, but it seems
to me you're needlessly multiplying entities, as a fellow named Ockham
once warned against. Most of the problems you correctly note can be
solved in other ways, and I don't feel the rest of them are serious
enough to warrant such a heavy-duty solution.
I'm certainly fairly new to debian-java, so take my comments with the
proverbial grain of salt.
-=Eric, hoping this made sense-- still a bit dazed here in .co.us. :-\
Reply to: