On 26/06/14 19:20, Omair Majid wrote:
> I talked to Mikolaj who thinks that ignoring the user-specified JVM
> (either through alternatives or JAVA_HOME) is a bug and can lead to
> surprises where an application is not using the JVM you may think it's
> using.
The element of surprise depends upon expectations which depend upon
knowledge of what one is doing. So, removing the surprise may not
involve revising the technology. I think what matters here is that what
a package does is clear and coherent enough for it to be documented and
understood. Clearly, a consistent behaviour across packages would be
preferred.
> This linking will also cause things to break when Java versions are
> bumped and we go from java-1.x.0-openjdk to java-1.y.0-openjdk or even
> if the OpenJDK directory changes name.
Why so? Don't the packages which use java-1.x.0-openjdk get flagged as
in need of update when java-1.y.0-openjdk is installed because of their
declared dependencies?
I can see that confusion on a user's part is possible when multiple Java
versions are installed (because a package may depend on an installed
Java version which is not currently the one pointed at by JAVA_HOME).
But that doesn't mean anything is wrong per se.
If a Java-dependent package is using a specific Java version then I
don't see how in general a user can decide that an earlier or later Java
will *just work* with that package. There are all sorts of reasons why
it might just break. The only safe way to do this is to also install an
appropriate updated version of the package when you install the updated
version of Java (or, conversely albeit less likely, when installing an
earlier Java downgrade to an earlier version of the dependent package).
I can see that this causes a package management problem but making
Java-dependent packages hostage to whatever setting the user picks for
JAVA_HOME is simply a rather brittle hack to work around the real problem.
> However, others, including Andrew Haley have suggested that it may lead
> to broken programs (and other surprises) when applications end up with a
> JVM that's different from what they expected.
i.e. the packager knows best. I think this is actually much more likely
to be true for most users. Maybe some users know better about what
version of Java works with what (probably only those who work on OpenJDK
:-) but even for them it's still a minefield.
> Mikolaj thinks it would be better if the packages did one of the
> following (in order of preference):
> 1. Fix upstream - convince them to respect $JAVA_HOME and use dlopen(3)
Well, I guess I'm agin it but . . .
If we are going to have packages use whatever they find via JAVA_HOME
then it needs fixing upstream. The best way is to provide a common
library which does the job for them.
Actually, a variant of the behaviour above could also serve the needs of
packages which require a fixed Java version. The client API could either
specify a specific version (e.g. 1.7.0), a range of versions (e.g.
1.7.*, 1.7.{3--23}, 1.7.23+) or could just accept whatever JAVA_HOME
points at. The library would need to ensure that a suitable version was
located and linked. This would not remove the need for dependent
packages to declare their dependencies but it would mean that any
monkeying around with Java versions could be handled in a more or less
fail-safe way.
> 2. Maintain Fedora-specific patch for dlopen(3)
Yuck!
> 3. App should use its own linker magic depending on java home (eg, shell
> script checks $JAVA_HOME and sets LD_PRELOAD)
Semi-yuck.
> 4. Fail if $JAVA_HOME is set
Hmm, I guess this is needed.
> And he prefers to avoid:
> 1. Java .so in default linker paths
Yuck!
> 2. Linker tricks to avoid depending on Java home (these are just
> workarounds for Java .so not being in default linker paths)
Yuck!
> 3. rpath
Yuck!
regards,
Andrew Dinn
-----------
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
