Goal: Increased Modularity?
lesmikesell at gmail.com
Thu Sep 6 13:15:06 UTC 2007
Nicolas Mailhot wrote:
> Le Jeu 6 septembre 2007 08:57, Les Mikesell a écrit :
>> How can that be
>> if you don't keep track of the JVMs themselves? Or if the packages are
>> supposed to be usable with unpackaged JVMs?
> They are *not* supposed to be usable with unpackaged JVMs.
That seems philosophically very wrong. Somewhat like not being able to
put an ogg file on your computer unless it is bundled with a known
version of a known player packaged with the same packaging conventions.
> Sorry. JPP
> won't maintain a huge pile of workarounds just because vendors are too
> lazy to follow common conventions and stick to them. Sometimes people
> release an adaptation layer for a specific vendor jvm and yes this
> layer is specific to this jvm but that's about it.
That's not supposed to be the case. If you supply the right JAVA_HOME
and start the right initial binary, it shouldn't matter where the actual
location is or anything about how it was packaged. And in fact that is
the case if you drop the sun binary under /usr/java and run things with
it instead of the arbitrarily moved jpackage version that you have to
have to do the app installs from the jpackage repo.
>> I don't particularly care how the files are managed or where they
> Then you won't ever understand why something works or not and how to
> fix your problems.
By "don't care" I mean I consider it completely arbitrary and have no
preference, not that I don't want to know. It's just annoying that the
packaged location is different from what Sun uses in their RPM version
and Sun should be somewhat of an authority on matters pertaining to java
- and even more annoying that in this long chain of questions I still
don't have the simple answer of where JAVA_HOME has been hidden for some
small variety of JVMs. I _do_ want to know that, but don't have much
interest in "understanding" arbitrary choices of paths that someone has
> The default is "just use the system jvm" if you
> don't want to follow the defaults you have to understand the
> conventions. That means reading the docs not deciding beforehand
> what's relevant and what's not.
Please, please - point me at the doc that says what JAVA_HOME is for
some (any?) jvm that has been hidden in the alternatives scheme of
symlinks. Preferable a document aimed at describing how to deal with an
already made choice of location and execute it, not the philosophy of
why the location and depth of symlinks that hide it was chosen.
The only philosophical concept I'm interested in here is that more than
one jvm can be run at once - and that should be expected if for nothing
else but testing under the next JVM release while keeping the old
version running in production.
lesmikesell at gmail.com
More information about the fedora-devel-list