(Created page with "<!-- Self Contained or System Wide Change Proposal? Use this guide to determine to which category your proposed change belongs to. Self Contained Changes are: * changes to is...") |
m (→Owner) |
||
(12 intermediate revisions by 3 users not shown) | |||
Line 24: | Line 24: | ||
== Summary == | == 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 == | == Owner == | ||
Line 31: | Line 31: | ||
This should link to your home wiki page so we know who you are. | This should link to your home wiki page so we know who you are. | ||
--> | --> | ||
* Name: [[User: | * Name: [[User:Msimacek| Michael Simacek]] | ||
* Name: [[User: | * Name: [[User:Mizdebsk| Mikolaj Izdebski]] | ||
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | <!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> | ||
* Email: msimacek@redhat.com | * Email: msimacek@redhat.com | ||
* Email: mizdebsk@redhat.com | * Email: mizdebsk@redhat.com | ||
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> --> | * Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->[mailto:sclark@fedoraproject.org Simon Clark] ([[User:sclark|sclark]]) | ||
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | <!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo) | ||
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | * FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address> | ||
Line 56: | Line 56: | ||
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development | ||
--> | --> | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1474878 #1474878] | ||
== Detailed Description == | == Detailed Description == | ||
Fedora | 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 == | == Benefit to Fedora == | ||
Users will be able to | Users (system administrators) will be able to change their java command 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?--> | ||
Line 72: | Line 109: | ||
* Proposal owners: | * Proposal owners: | ||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
** Adjust javapackages-tools to provide default Java setting in /etc/java/java.conf | |||
* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do other developers have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
* Release engineering: [https://pagure.io/releng/ | * Release engineering: [https://pagure.io/releng/issue/6831] (a check of an impact with Release Engeneering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES --> | ||
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuid required? include a link to the releng issue. | <!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)? Is a mass rebuid required? include a link to the releng issue. | ||
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | ||
Line 127: | Line 165: | ||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
* Contingency mechanism: | * Contingency mechanism: revert to using single alternatives provider <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | <!-- When is the last time the contingency mechanism can be put in place? This will typically be the beta freeze. --> | ||
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | <!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? --> | ||
* Blocks release? | * Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
== Documentation == | == Documentation == | ||
Line 147: | Line 184: | ||
--> | --> | ||
[[Category: | [[Category:ChangeAcceptedF27]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> |
Latest revision as of 19:55, 26 October 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
- Name: Michael Simacek
- Name: Mikolaj Izdebski
- Email: msimacek@redhat.com
- Email: mizdebsk@redhat.com
- Release notes owner: Simon Clark (sclark)
Current status
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)
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)