Re: Goal: Increased Modularity?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx


--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux