Here are some thoughts about how to make OpenJDK easily maintainable on Fedora. Achieving this goal will require changes to OpenJDK, updates to the Fedora implementation of the JPackage conventions and an rpm patch.
Here is a list of problems and a strawman solution for each. Each item needs careful investigation to determine the most appropriate solution.
OpenJDK Changes
Read OpenSSL certs directly
Now: We generate a cacerts file from certificates shipped with the Fedora OpenSSL package.
Future: OpenJDK should parse the OpenSSL certificates directly. That would give us one point of maintenance for the certificates and allow OpenJDK to take advantage of new certificates when OpenSSL is updated.
Replace font.properties with fontconfig
Now: fontconfig.Fedora.properties hard-codes Fedora fonts that OpenJDK uses.
Future: OpenJDK should use fontconfig to determine which fonts to use, to match desktop font preferences.
Read glibc timezone and locale data
Now: OpenJDK bundles its own set of timezone and locale data.
Future: OpenJDK should read glibc’s timezone and locale data. This provides a single point of maintenance for these data and eliminates the need to reinstall OpenJDK, or run a separate tool like tzupdater, whenever timezone or locale data updates are required.
Security policy and provider configuration under /etc/java
Now: OpenJDK security policies are installed and configured under /usr/lib/jvm/java-$version-$vendor/jre/lib/security.
Future: OpenJDK security policies and providers should be configured from /etc/java, since /etc is the standard location for administrator-edited configuration files. If configuration were under /etc/java/java-$version, the settings could be shared between same-versioned JDKs. There should also be a .d directory so that new security policies and providers can be easily installed by separate packages.
Endorsed directories: /usr/lib*/java-$version/endorsed, /usr/share/java-$version/endorsed
Now: OpenJDK loads endorsed jars from /usr/lib/jvm/java-$version-$vendor/jre/lib/ext.
Future: OpenJDK should load endorsed jars from locations like /usr/lib/java-$version/endorsed and /usr/share/java-$version/endorsed so that separate packages can easily install and uninstall additional endorsed jars.
Properties files in /etc/java
Now: OpenJDK loads .properties files from /usr/lib/jvm/java-$version-$vendor/jre/lib.
Future: OpenJDK should load .properties files from /etc/java, since /etc is the standard location for config files.
Split out bundled code, push Sun patches upstream
Now: OpenJDK bundles source code packages from many other projects.
Future: Using the new module system or some other mechanism, OpenJDK should use the system-installed versions of these packages. Any modifications to these projects that Sun has been maintaining in their tree should go upstream.
Default JNI load path, to support loading 32-bit and 64-bit JNI libraries from the same jar
Now: System.loadLibrary relies on the default library paths.
Future: System.loadLibrary should also look in standard paths where packages can install JNI libraries: /usr/lib/jni on 32-bit JVMs and /usr/lib64/jni on 64-bit JVMs.
Default /usr/share/java “CLASSPATH” directory
Now: JPackage provides a build-classpath script to build CLASSPATH settings from jars found in system-default locations such as /usr/share/java.
Future: OpenJDK’s module system should resolve dependencies from these system-default locations, obviating the build-classpath script. Related: Red Hat bug 170128.
OpenJDK Package Changes
Multiarch support in jpackage-utils
Now: the jpackage-utils package is built as a noarch package but contains references to /usr/lib.
Future: jpackage-utils should also support JDK installations in /usr/lib64. Doing so will raise questions about how JDK alternatives are handled, since they are based in /usr/lib. It may be best to change the alternatives tool itself to special-case /usr/lib and /usr/lib64.
Simplify package split to base, javadoc
Now: JDK packages are split up into base (JRE), devel, demo, src and javadoc subpackages.
Future: We could reduce this to just a base “java” package, which includes the JRE, development tools, demos and src.zip. javadoc will still need to remain a separate subpackage because of its installed size.
Simplify alternatives to just “java”
Now: There are many JDK primary alternatives: java, javac, jre_$vendor, $jre_$version, java_sdk_$vendor, java_sdk_$version, libjavaplugin.so
Future: With the simplified package split we could reduce this list to two primary alternatives: java and javadoc. But simplification may not be required if everyone just uses system-switch-java instead of dealing with alternatives directly.
RPM Changes
Fix rpm $1 arch-specific bug
Now: Red Hat bug 127359 prevents correct upgrading of alternatives symlinks in multilib installations.
Future: The bug must be fixed.