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