From Fedora Project Wiki
(Rewrite description)
Line 24: Line 24:


== Summary ==
== Summary ==
Alternatives can be used to specify which Java installation should be the default for the system. Currently, changing the default java command causes not only a change to the /usr/bin/java symlink, but also affects the which runtime is used for system installed Java applications. We propose introduction of separate setting for system-wide java applications.
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 ==
== Owner ==
Line 59: Line 59:


== Detailed Description ==
== Detailed Description ==
Fedora allows parallel installation of multiple Java runtime environments and it uses alternatives mechanism to allow the user to switch between them. JDK packages provide a set of alternatives symlinks for it's executables. The java symlink is used to determine the java command (/usr/bin/java), but also determines which runtime environment is used to run system-wide Java applications installed from RPMs, such as maven or eclipse. While in theory different Java runtime environments are drop-in replacements for each other, in practice some of the applications may stop working properly. Users usually install alternative JDKs in order to run their own applications and don't expect that changing the java command will have effect on the system applications. By introducing a separate setting for system-wide java, we would avoid this problem.
Java applications are not directly executable and thus they typically ship a
We propose specifying default Java runtime for RPM-managed applications in /etc/java/java.conf (this is already possible, but not currently used). Administrators would still be able to override the system default if they need to.
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
* 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 alternatives
 
=== 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
(probably legacy). He either does this system-wide and permanently using
alternatives (needs root), or temporarily by placing java command of the
desired provider on PATH. Now, when he runs any java application
in the system installed from RPM, such application will be run with the
JVM that was put on PATH, 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).
 
Also, the current behavior is not consistent with what other language stacks do in Fedora. Scripting
languages mostly use absolute paths to interpreters in script shebangs to
ensure that those scripts are run by the intended interpreter. The current
behavior of JVM lookup can be compared to using /usr/bin/env in shebangs,
which is generally avoided in Fedora-packaged software.
 
=== 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.
PATH won't be considered anymore. 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 ==
== Benefit to Fedora ==
Users will be able to switch their default Java runtime without the risk of affecting system-wide Java applications (installed from RPMs).
Users will be able to change their java command (via PATH or alternatives)
without the risk of impacting system-wide applications installed from RPMs.
    
    
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?-->
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new functionality, what capabilities does it bring? Why will Fedora become a better distribution or project because of this proposal?-->

Revision as of 15:16, 28 June 2017


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

Current status

  • Targeted release: Fedora 27
  • Last updated: 2017-06-28
  • Tracker bug: <will be assigned by the Wrangler>

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
  • 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 alternatives

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 (probably legacy). He either does this system-wide and permanently using alternatives (needs root), or temporarily by placing java command of the desired provider on PATH. Now, when he runs any java application in the system installed from RPM, such application will be run with the JVM that was put on PATH, 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).

Also, the current behavior is not consistent with what other language stacks do in Fedora. Scripting languages mostly use absolute paths to interpreters in script shebangs to ensure that those scripts are run by the intended interpreter. The current behavior of JVM lookup can be compared to using /usr/bin/env in shebangs, which is generally avoided in Fedora-packaged software.

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. PATH won't be considered anymore. 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 will be able to change their java command (via PATH or alternatives) 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)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

N/A (not a System Wide Change)

User Experience

N/A (not a System Wide Change)

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: revert to using single alternatives provider
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? No

Documentation

N/A (not a System Wide Change)

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/Decouple_system_java_setting_from_java_command_setting&oldid=495802"