Goal: Increased Modularity?

[Les Mikesell]

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
>> live.
> 
> 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 
already made.

> 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.

-- 
   Les Mikesell
    lesmikesell at gmail.com