Symlinks to /usr/bin/run-java-tool are not created in /usr/bin for all tools in the 'bin' directory of a JVM. The user VM setting for these tools is ignored and the system VM version is always used (since the system VM is added to PATH via /etc/env.d/20java). This causes a variety of errors when the system VM and user VM differ. Reproducible: Always Steps to Reproduce: 1. Install any two JVMs, e.g. sun-jdk-1.4 and sun-jdk-1.5. 2. Using java-config-2, set system VM and user VM to different VMs, e.g. system=sun-jdk-1.4, user=sun-jdk-1.5. 3. env-update && source /etc/profile 3. As user: which serialver Actual Results: The 'which' command finds serialver in the system VM's bin directory, not /usr/bin. Expected Results: All Java VM tools should reflect the user's choice of JVM. 'which serialver' should have found '/usr/bin/serialver' which in turn should be a symlink to /usr/bin/run-java-tool. This scriptlet identifies the broken tools for a particular JVM (run as user): --------- cd /opt/sun-jdk-1.5.0.10/bin # or any other JVM for f in *; do if [ -h /usr/bin/$f ] ; then echo "GOOD: $f -> $(readlink /usr/bin/$f)" else t=$(which $f 2>/dev/null) if [ $? = 0 ] ; then echo "BROKEN: $f -> $t" else echo "MISSING: $f" fi fi done ---------- Tools reported as BROKEN execute the wrong version when user and system VMs differ. Those reported MISSING aren't found at all. On my system (JVMs: system sun-jdk-1.4.2.13, user sun-jdk-1.5.0.10), the above reports the following JVM tools are not properly wrapped: ---------- BROKEN: ControlPanel -> /opt/sun-jdk-1.4.2.13/jre/bin/ControlPanel BROKEN: extcheck -> /opt/sun-jdk-1.4.2.13/bin/extcheck BROKEN: HtmlConverter -> /opt/sun-jdk-1.4.2.13/bin/HtmlConverter BROKEN: idlj -> /opt/sun-jdk-1.4.2.13/bin/idlj BROKEN: java-rmi.cgi -> /opt/sun-jdk-1.4.2.13/bin/java-rmi.cgi MISSING: jinfo BROKEN: jmap -> /opt/sun-jdk-1.4.2.13/bin/jmap MISSING: jps MISSING: jsadebugd MISSING: jstack MISSING: jstat MISSING: jstatd BROKEN: keytool -> /opt/sun-jdk-1.4.2.13/bin/keytool BROKEN: kinit -> /usr/bin/kinit BROKEN: klist -> /usr/bin/klist BROKEN: ktab -> /opt/sun-jdk-1.4.2.13/bin/ktab BROKEN: native2ascii -> /opt/sun-jdk-1.4.2.13/bin/native2ascii BROKEN: orbd -> /opt/sun-jdk-1.4.2.13/bin/orbd MISSING: pack200 BROKEN: policytool -> /opt/sun-jdk-1.4.2.13/bin/policytool BROKEN: serialver -> /opt/sun-jdk-1.4.2.13/bin/serialver BROKEN: servertool -> /opt/sun-jdk-1.4.2.13/bin/servertool BROKEN: tnameserv -> /opt/sun-jdk-1.4.2.13/bin/tnameserv MISSING: unpack200
*** Bug 210122 has been marked as a duplicate of this bug. ***
for sun-jdk-1.6.0.06: GOOD: appletviewer -> run-java-tool GOOD: apt -> run-java-tool MISSING: extcheck MISSING: idlj GOOD: jar -> run-java-tool GOOD: jarsigner -> run-java-tool GOOD: java -> run-java-tool GOOD: javac -> run-java-tool GOOD: javadoc -> run-java-tool GOOD: javah -> run-java-tool GOOD: javap -> run-java-tool GOOD: jconsole -> run-java-tool GOOD: jdb -> run-java-tool MISSING: jhat MISSING: jinfo MISSING: jmap MISSING: jps MISSING: jrunscript MISSING: jsadebugd MISSING: jstack MISSING: jstat MISSING: jstatd GOOD: keytool -> run-java-tool MISSING: orbd MISSING: pack200 MISSING: policytool GOOD: rmic -> run-java-tool GOOD: rmid -> run-java-tool GOOD: rmiregistry -> run-java-tool MISSING: schemagen MISSING: serialver MISSING: servertool MISSING: tnameserv MISSING: unpack200 MISSING: wsgen MISSING: wsimpo MISSING: native2ascii
*** Bug 231710 has been marked as a duplicate of this bug. ***
Here's my idea: - java-config generates symlinks dynamically as an *union* of binaries of all installed VM's (in their PATH variable? or just bin + jre/bin) - it keep the list of created symlinks in some file so they don't become orphaned - on each VM install/uninstall/reinstall the symlinks are regenerated (added, removed), and there can be manual regeneration command too - on java-config-2 uninstall symlinks are removed in prerm/postrm - there could be a file defining blacklist (known collisions) - those symlinks wouldn't be created - it should check thoroughly that created symlinks don't overwrite something else, if those collisions are detected, it probably should not make the VM installation die though, just warn and don't create the symlink - con: when a package being installed collides with java-config's symlink, portage won't detect it as belonging to java-config, but people should figure out, too bad, if there's no defined way of updating CONTENTS dynamically should work, not? we just need to be very careful so this doesn't end up as the (gasp) eselect compiler :)
>=dev-java/java-config-2.1.8 now installs _hopefully_ all wrappers. Reopen if any missed.
Java-config is not creating a link for unpack200. (Curiously, though, it does create a link for pack200.) GOOD: appletviewer -> run-java-tool GOOD: apt -> run-java-tool GOOD: ControlPanel -> run-java-tool GOOD: extcheck -> run-java-tool GOOD: HtmlConverter -> run-java-tool GOOD: idlj -> run-java-tool GOOD: jar -> run-java-tool GOOD: jarsigner -> run-java-tool GOOD: java -> run-java-tool GOOD: javac -> run-java-tool GOOD: javadoc -> run-java-tool GOOD: javah -> run-java-tool GOOD: javap -> run-java-tool GOOD: javaws -> run-java-tool GOOD: jconsole -> run-java-tool GOOD: jcontrol -> run-java-tool GOOD: jdb -> run-java-tool GOOD: jhat -> run-java-tool GOOD: jinfo -> run-java-tool GOOD: jmap -> run-java-tool GOOD: jps -> run-java-tool GOOD: jrunscript -> run-java-tool GOOD: jsadebugd -> run-java-tool GOOD: jstack -> run-java-tool GOOD: jstat -> run-java-tool GOOD: jstatd -> run-java-tool GOOD: jvisualvm -> run-java-tool GOOD: keytool -> run-java-tool GOOD: native2ascii -> run-java-tool GOOD: orbd -> run-java-tool GOOD: pack200 -> run-java-tool GOOD: policytool -> run-java-tool GOOD: rmic -> run-java-tool GOOD: rmid -> run-java-tool GOOD: rmiregistry -> run-java-tool GOOD: schemagen -> run-java-tool GOOD: serialver -> run-java-tool GOOD: servertool -> run-java-tool GOOD: tnameserv -> run-java-tool MISSING: unpack200 GOOD: wsgen -> run-java-tool GOOD: wsimport -> run-java-tool GOOD: xjc -> run-java-tool This is with sun-jdk-1.6.0.22 and java-config-2.1.11. I am unable to reopen this bug, but it should be reopened unless this can be fixed immediately.
