"/usr/lib/jvm/default-java" not changed by "sudo update-alternatives --config java"

[Raffi Enficiaud]

Binary package hint: java-common

After a
sudo update-alternatives --config java

setting for instance the sun JVM as the default, the link
/usr/lib/jvm/default-java

still points to "java-6-openjdk". However, in
/usr/lib/java-wrappers/jvm-list.sh

the "default" is the first java in $__jvm_all, which is then used in
/usr/lib/java-wrappers/java-wrappers.sh

called by some programs (such as for instance Freemind).

I am running Maverick, java-common 0.38.

[Niels Thykier (niels-thykier)]

Hi

What you see here is "intended behavior" (at least in case of the default-java symlink and update-alternatives). The issue here is probably that what Java packagers understand with "default" from what users expect. "default-java" has been used by packagers to denote the default Java implementation used for compiling Java packages.

I can clearly see how you would come to the conclusion you did and I have taken this up with the Debian Java Team. Though any changes to how default-java behaves is out of the question for Maverick (too many packages depend on the behavior). Most likely we will introduce a new symlink for this purpose in Natty (or later).

As for java-wrappers and how it handles this case. I suspect the tool will need an update to properly handle this case; whether this can make it into Maverick is an entirely different case. Since I do not work on this tool I will not make any promises on this; however, you should be able to work around this issue by using JAVA_FLAVOR (see man 7 java-wrappers).

~Niels

[Niels Thykier (niels-thykier)]

Taking this (in regards to solving the default-java issue). We probably need a separate bug for java-wrappers.

[Raffi Enficiaud (raffi-enficiaud-x)]

Hi,

Thank you for the comment. I agree for the risk in changing the behaviour. However I should add that any java program relying on java-wrapper will get run by open-jdk, and so the wrapper would have no effect (unless I missed something).

Do you think the dependency problem remain the same if the order of the jvm list is altered during the "sudo update-alternatives --config java" ? For instance, changing (in jvm-list.sh):

__jvm_all="$__jvm_default /usr/lib/jvm/* $__jvm_ibm $__jvm_sun4 $__jvm_sablevm $__jvm_kaffe"
to something like
__jvm_all="$__jvm_sun6 $__jvm_default /usr/lib/jvm/* $__jvm_ibm $__jvm_sun4 $__jvm_sablevm $__jvm_kaffe"

I guess yes, but I am not sure...

Regards,
Raffi

[Niels Thykier (niels-thykier)]

Hi

The change you suggest will solve your particular problem, but for someone wanting to do the "other way" transformation (etc. sun-java6 -> openjdk-6) will now have a problem.
  That being said, I think the reverse is probably less likely to happen in the real world and your solution here will probably be a decent work-around for Maverick. The long term solution is probably to update java-wrappers to prefer the system default java if it fulfills the requirements (also it should probably be updated to not include 4+ JVMs that are now removed from Debian) and then fall back to its chosen order (if the system default is not good enough). Though again, I am not working on java-wrappers so I will not make any decisions here.

On a side note: openjdk-6 is a vastly better choice than e.g. gcj/gij or some of the now removed JVMs such as sablevm or kaffe. I suspect the /usr/lib/jvm/* might have caught the gcj/gij before the openjdk-6; this is likely the reason why it was added early in the list.

~Niels

[Matthias Klose (doko)]

No. This should not be done. Relying on an alternative for a build makes problems much harder to debug, if you first have to find out which alternative is actually used, and which alternative is used for the build.

I am fine with improving user experience, but the change in the proposed form will obfuscate the build process.