Goal: Increased Modularity?

[Richi Plana]

On Thu, 2007-09-06 at 15:15 -0500, Les Mikesell wrote:
> Nicolas Mailhot wrote:
> > Le jeudi 06 septembre 2007 à 08:15 -0500, Les Mikesell a écrit :
> > 
> >> That seems philosophically very wrong.
> > 
> > ...
> 
> Do you disagree with the idea that a JVM executing java bytecode should 
> be very much like a media player playing a media file?  That is, 
> installing the data should not be dependent on having some particular 
> player or JVM available that might or might not be used to manipulate it 
> later.  Why can't I have the app before the JVM or supply my own JVM?

Probably not the best example. A piece of data (a media file in your
example) has so many different kinds of applications associated with it,
some might even be on different systems and the data is exported via a
number of means (http, nfs, etc.) Java bytecode, unless they're applets,
are much easier to predict requirements for. There is a huge probability
that they will need a JVM, and unlike media players, from outside,
they're designed to function in the same way.

As examples go, it's closer to say that JVMs are to Java applications or
even just bytecode what glibc is to native applications.

In Fedora, openoffice.org-core-2.2.0 Requires the virtual package java.

You CAN have the app before the JVM, I suppose, the same way you can
"rpm --nodeps -ivh openoffice.org-core.2.2.0....", but they'd just be
bytes taking up space in your filesystem.

> No one has given a usable answer for even a single value of JAVA_HOME 
> for a single packaged jvm version.  Or the location of the document that 
> provides this necessary information.  I'm sorry if that was too much to 
> ask.

Honestly, I tried to answer here
(https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00396.html), here (https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00414.html) and here (https://www.redhat.com/archives/fedora-devel-list/2007-September/msg00490.html), but I guess I'm misunderstanding the question.
--

Richi Plana