I have run into a suspicious situation while using eselect to change the user java-vm, in which the java VM is Java7 while maven is using Java8 due to the remaining JAVA_HOME environment variable. I have obeyed the following line from https://wiki.gentoo.org/wiki/Java : "source-ing the profile is no longer needed for updates to the user's or the system's VM." Here is a shell excerpt that exposes the undesired behavior: cipi@pink ~/src/archiva $ eselect java-vm list Available Java Virtual Machines: [1] icedtea-bin-7 user-vm [2] icedtea-bin-8 system-vm cipi@pink ~/src/archiva $ java -version java version "1.7.0_101" OpenJDK Runtime Environment (IcedTea 2.6.6) (Gentoo icedtea-7.2.6.6) OpenJDK 64-Bit Server VM (build 24.95-b01, mixed mode) cipi@pink ~/src/archiva $ mvn -version Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T18:41:47+02:00) Maven home: /usr/share/maven-bin-3.3 Java version: 1.8.0_91, vendor: Oracle Corporation Java home: /opt/icedtea-bin-3.0.1/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix" cipi@pink ~/src/archiva $ echo $JAVA_HOME /etc/java-config-2/current-system-vm cipi@pink ~/src/archiva $ bash -l cipi@pink ~/src/archiva $ echo $JAVA_HOME /home/cipi/.gentoo/java-config-2/current-user-vm cipi@pink ~/src/archiva $ mvn -version Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T18:41:47+02:00) Maven home: /usr/share/maven-bin-3.3 Java version: 1.7.0_101, vendor: Oracle Corporation Java home: /opt/icedtea-bin-7.2.6.6/jre Default locale: en_GB, platform encoding: UTF-8 OS name: "linux", version: "4.4.6-gentoo", arch: "amd64", family: "unix" I believe I got here by running eselect java-vm set user 1 in another shell session. Please update the wiki page to warn users that, actually, sourcing the profile is still needed. Reproducible: Always
I don't know who originally wrote that line. I guess the point it was trying to make is that if the system VM changes to a different system VM or if the user VM changes to a different user VM, then you no longer have to source the profile. This doesn't work if you set a user VM where there previously was none. It also wouldn't work if the user VM were to change from set to unset although the tools don't currently offer that feature. This is because even though JAVA_HOME always points to a symlink, the location of that symlink depends on whether a user VM is set or not. It would probably be easier to say that the profile should be sourced just in case. Do you agree with this assessment?
One more thing. The statement actually did hold true, even in those cases I mentioned, in so far as calling "java" or any other Java tool in the PATH would still call the right version as this is not dependent on the JAVA_HOME variable.
In fact, this only fails for mvn in particular because it installs the upstream launcher script instead of using our infrastructure. This is arguably a bug in the maven-bin package and any other Java package that uses upstream launchers but such packages are ones I tend not to get involved with. Nevertheless, it would be helpful if JAVA_HOME pointed to the right place so your point remains valid. Okay, I'm really done now. :)
You are correct: after the initial setup of the user VM I never had to source the profile, since JAVA_HOME in newer login shells points to $HOME/.gentoo/java-config-2/current-user-vm My personal preference is to use the system VM setting by default, and only switch temporarily to other JDKs to check bugs etc. For this reason I think unsetting the user VM could be a nice feature. I can happily just remove $HOME/.gentoo/java-config-2, or set it to coincide with the system VM (which seems like a better idea after learning this). So, not having an unset is fine. In my opinion the best course of action would be simply to add a word of warning about this situation, where the system/user VM is set for the first time. I am sure not many fall into this convoluted trap. I did report it so that someone with wiki access can take action and document it. I think java packages provided by gentoo should work seamlessly with java-config. However, as developers we often have to switch compilers, use tools simply unpacked in some folder, switch between various versions of the same package just to check something out etc. Most of them rely on JAVA_HOME, because this env variable is as old as Java (I remember 1.1 :D), and well... it would be a nuisance not to have it work properly for such cases. And, as a plus, it eases maintenance of packages that rely on it. Kudos for the java-config system! It's simply great, and I am happy to help make it better.
Thanks for the feedback. I have now added a note about this to the wiki. I may add an unset feature to java-config and/or eselect-java on their next releases. Someone else asked about it the other day. It's not documented as far as I know because it probably wasn't meant for end-users but another way to switch the VM temporarily is to set the GENTOO_VM environment variable. You'll probably find this very useful. This won't be changing any time soon. It's used by the Java eclasses because sometimes packages need to be built with a different VM than the one that's been selected. Feel free to document this on the wiki. You can edit it yourself, you know. ;)
