The new java system sets java 1.4 as the system wide JVM, and that is fine because many packages rely on 1.4 for compiling. Bue when a user sets his preferred vm, even if a 1.5 version, JAVA_HOME will default to the system JVM (1.4). The java upgrade guide points to this problem telling "This will be an issue until the particular application is converted to use the new eclasses." JAVA_HOME is the default system variable for specifying the vm since Java was born. There are too many applications that rely on this var (and an 1.5 vm) that don't have and won't have an ebuild (sun's glassfish ?). Maybe it would be just easier to adapt java-config-2 to the previous funcionality for setting the user-vm (like the workaround described on the upgrade guide) than to (try) to create/adapt every app out there to this gentoo-centric config.
This is a known issue is pretty tricky to workaround. The problem is that java-config-1 reads JAVA_HOME to figure out what VM is being used. And java-config-1 needs to be able to work for all the ebuilds using the original eclasses. I'm currently testing a way to get around this. Right now, we keep track of the 'handle' as java-config-2 knows a vm in the environment for the generation-1 system vm. Since we have that, we can use java-config-2 to get the JAVA_HOME for the generation-1 system vm. And, by using pre phase hooks, we can ensure it is set for each ebuild phase. So, this requires a few tweaks to java-pkg.eclass, for the phase hooks, and for the actual setting of JAVA_HOME. It also requires a few minor tweaks to filter JAVA_HOME from the env files used for generation-1 compatibility. All the VMs will need to be revbumped to make sure they get the updated env files, and a user would need to set their generation-1 system vm again, but the revbump should take care of that. So, at that point, JAVA_HOME wouldn't be in the environment. So, I suppose then that the 'workaround' in the guide should always be used.
A consequence of my solution is that java-config-1 wouldn't be able to know what VM is currently being used without modification.
The problem I'm experiencing isn't about ebuilds, but any Java application which should run unmodified on gentoo (without an ebuild), so, JAVA_HOME must always exist. Just found out that the java plugin isn't working (I'm using a 1.5 jdk as my user vm and the plugin's version is 1.4) should another bug be filled ?
Yes, file a separate bugs for separate issues (as in, this issue is unrelated to the nsplugin). When I was saying 'the problem is...', I meant, that is why JAVA_HOME currently points to the generation-1 system vm.
Tell me, is it possible to fix it this way: JAVA_HOME points to the system jvm (gen 2) When an ebuild depends on java, check if it specifies the required JVM. -> If not, set JAVA_HOME, classpath, etc to an 1.4 VM -> Else set JAVA_HOME to the desired ebuild classpath This way, can we get rid of generation-1 but keep JAVA_HOME ? It's really important, for example, if you have any app that requires java 1.5 without an ebuild, like sun's glassfish (if we are talking about commercial stuff) or any homebrew java app. It's true that not long ago 1.5 was not that stable and 1.4 was needed to keep everything up, but as the launch of 1.6 is imminent, 1.5 is becoming standard and 1.4 is only used on rare scenarios. The advantages on the 1.5 vm are really worth it.
You can always put such line in ~/.bashrc: export JAVA_HOME=$(java-config --jdk-home)
This has been addressed with java-config 1.3.1 and java-config 2.0.27.
