Goals
- Decide/Find out if we support multilib for Java libraries and applications running on RHEL (and by definition Fedora)
- Are there any use cases for using 32bit JVM on 64bit OS which we should support
- Find optimal solutions/transitions to fix current issues
Current State
- JVM (openjdk) itself supports multilib just fine. You can install and run both 32 and 64bit versions on 64bit host operating system.
- Most applications and libraries in Java are architecture independent (noarch) packages and are therefore unaffected by choice of JVM as far as packaging is concerned
- We have numerous JNI libraries which do not support multilib (i.e. 32 and 64 versions install different files in the same place) - see jansi-native
- (my) Past attemt to quickly solve one bug (https://bugzilla.redhat.com/show_bug.cgi?id=665576) led to even more confusion (i.e. introduction of %{_javajnidir)
Proposed solutions
Properly support multilib
This is relatively hard to archieve and certainly needs modifications to jpackage classpath script family (build-classpath, build-jar-repository etc). Application scripts would have to find out which JVM they will run on instead of relying on host arch as they do now.
Non exhaustive list of problems:
- Dealing with dependencies is a problem. Example: jansi requires jansi-native package which is using JNI. Assuming 32bit JDK and jansi-native.x86_64 is installed RPM will not complain since all dependencies are OK from rpm POV. However using jansi is not possible. Alternative is to always pull in both subarchitectures (which is ugly)
- Even JARs with same content have different metadata when built twice (usually date in pom.properties or MANIFEST.MF). We would have to make sure this does not happen for multilib packages.
Solving even previous small list of issues is non-trivial and would in any case complicate packaging. Question is:
Is it worth adding complexity to packaging multilib-aware Java stack? Are there good enough use cases where workarounds don't exist?
Openly do not support 32bit JNI on 64bit OS
Note that this does not mean we do not support 32 bit JDK on a 64bit OS, just that our stack would not support for example installation of eclipse-jdt.i686 on 64 bit system. Advantage of this solution is that it should be more simple to implement. Even currently this does not work well but we half-support it in our systems complicating a lot of things.
Directory layout proposal:
change %{_jnidir} to %{_libdir}/jni - or keep it as it is, no big difference
%{_javadir} - (default: /usr/share/java) - noarch jars - even if they are different on different architectures due to metadata changes inside - i.e. ignore mulilib
%{_jnidir} - so files for use by JNI-aware java packages and JAR files containing so files such as jansi-native (optionally in subdirectories)
Additional notes:
- I intentionally avoided %{_libdir}/%{name} since we want to be able to recognize JNI so files easily using repoquery (and it seemed generally nicer)
- %{_javajnidir} seems confusing so we should get rid of it. Just one package seems to be using it currently. Fortunately hasn't been propagated yet
- I'd add option to place even noarch jars into %{_jnidir} if the packager wants to ensure multilib for noarch parts of his arch-specific packages.