On systems with SYMLINK_LIB=no & LIBDIR_x86=lib eselect-java assume MULTILIB_MODE=none and manage symlinks only in /usr/lib dir. Code example: is_multilib() { local libdirs=$(list_libdirs) if has lib32 ${libdirs} && has lib64 ${libdirs}; then return 0 else return 1 fi }
The code quoted above was actually part of the java-nsplugin module, which was dropped in 0.2.0 at the end of 2015. However, I believe this is still an issue due to the following line in the java-vm module. VM_BASE="${EROOT}/usr/lib/jvm/" I'll have a play with it.
Ugh, this is more complicated than I thought. For starters, eselect only provides you with a relatively dumb way to get all the libdirs, not the primary one. I guess we'd have to use $(get_libdir) at build time to write this into the module but then it would break without a remerge if someone does the migration later? I'm thinking it may be more sensible to move to a location like /usr/libexec but I would have to ensure a smooth migration. /usr/libexec/eselect-java/run-java-tool.bash looks for /usr/lib/jvm/${GENTOO_VM} in some instances. This script is run every time you call java or javac so anything I do in here will need to be cheap. java-vm-2.eclass also gets it wrong as it sets JAVA_VM_DIR="/usr/lib/jvm". java-config duplicates the eselect functionality so that will be broken too. Perhaps it's time to finally remove that functionality.
After discussing this in #gentoo-dev, I decided to leave things in /usr/lib. It didn't affect the 17.1 migration in the way that I thought it did, the libexec migration was too much of a headache, and this isn't such a bad location anyway. Since the original issue was already fixed, I'll close this now.
