Decouple system java setting from java command setting

Summary

By default, Java applications installed from RPMs are run with JVM found on PATH. We propose to run them with default system JVM, not considering PATH. Users will still be able to override the default using JAVA_HOME environment variable as before.

Owner

Name: Michael Simacek
Name: Mikolaj Izdebski
Email: msimacek@redhat.com
Email: mizdebsk@redhat.com
Release notes owner: Simon Clark (sclark)

Current status

Targeted release: Fedora 27
Last updated: 2017-10-26
Tracker bug: #1474878

Detailed Description

Java applications are not directly executable and thus they typically ship a launcher script that performs the lookup of the JVM executable used to run the application and setups its environment. In Fedora, applications packaged as RPMs ship launcher scripts (most commonly generated using %jpackage_script macro) that delegate the setup to helper routines provided by javapackages-tools.

Currently (Fedora 26), the lookup of a JVM by javapackages-tools works as follows:

it reads java.conf configuration file from config paths (default /etc/java/java.conf)
if the current environment contains JAVA_HOME variable (typically it doesn't), JVM executable is looked up there
if the configuration specifies JAVA_HOME (by default it doesn't), JVM is looked up there
it tries to find JVM in java/jre subdirs of JVM_ROOT (by default /usr/lib/jvm). Those subdirs are managed by "jre"/"java_sdk" alternatives. This is the code path that is triggered by default. The /usr/lib/jvm alternative symlink is a slave of "java" configuration, so changing "java" alternatives will set it to different value or unset it, if the alternative provider doesn't specify the slave configuration.
otherwise JVM executable is looked up on PATH, using which java. With default PATH setting on Fedora, this will be /usr/bin/java, which is a symlink managed by "java" alternatives setting

Disadvantages of the current behavior

Let's say a user wants to change his java command to a different provider, because he needs to run an application that requires a different JDK. He does this using alternatives (needs root), changing the provider of "java". This will not only change what /usr/bin/java points to, but because "jre" and "java_sdk" alternatives settings are defined as slave, it will also change the JVM system applications are run with. Now, when he runs any java application in the system installed from RPM, such application will be run with the JVM set in alternatives, not with the Fedora-supported one. The user might not realize that the application is written in Java and the application may not behave correctly if it's not compatible with given JVM (i.e. a legacy one).

Proposed behavior

If JAVA_HOME is not set (neither in the environment, nor in configuration), it is set to a default value that points to the currently supported default Java implementation. The default would be stored in javapackages-tools (the package providing the lookup functions). For Fedora 27, this would be /usr/lib/jvm/java-1.8.0-openjdk, which is a symlink pointing to latest version of openjdk 8, provided by java-1.8.0-openjdk package. The system administrator would still be able to change the default system-wide JVM for applications in java.conf configuration file. Temporary changes of JVM would still be possible using JAVA_HOME environment variable.

The change would be implemented by altering the lookup functions in javapackages-tools and updating the package in Fedora. Note that we (the change owners) are both upstream and Fedora maintainers of javapackages-tools.

Benefit to Fedora

Users (system administrators) will be able to change their java command without the risk of impacting system-wide applications installed from RPMs.

Scope

Proposal owners:
- Adjust javapackages-tools to provide default Java setting in /etc/java/java.conf

Other developers: N/A (not a System Wide Change)

Release engineering: [1] (a check of an impact with Release Engeneering is needed)

- List of deliverables: N/A (not a System Wide Change)

Policies and guidelines: N/A (not a System Wide Change)

Trademark approval: N/A (not needed for this Change)