Line 151: | Line 151: | ||
** temurin-8-jdk | ** temurin-8-jdk | ||
** temurin-8-jre | ** temurin-8-jre | ||
* Warning, jdk contains both jre and jdk, so if you install jdk and jre (of same version) you will have two java alternatives masters, and one javac master. | |||
sudo dnf install adoptium-temurin-java-repository | |||
== Feedback == | == Feedback == |
Latest revision as of 11:12, 4 November 2024
Adjust java/java-devel requires to multi-vendor JDK world and replace legacy JDKs by third party Eclipse Temurin repositories
Summary
Adjust java/java-devel provides/requires
to multivendor world and obsolete all non-system LTS JDKs (java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk in time of writing) by appropriate, properly integrating, RPMs from Eclipse Adoptium repositories.
Owner
- Name: Jiri Vanek
- Email: <jvanek@redhat.com>
- Product: java and java stack
- Responsible WG: java-sig (java and java-maint)(which no longer exists)
- rcm ticket: https://pagure.io/releng/issue/TODO
- named side tag ticket: tbd
Current status
- Targeted release: Fedora Linux 42
- Last updated: 2024-11-04
- Writing in progress
- Announced
- Discussion thread
- FESCo issue: #3277
- FESCo exception/denial to enable temurin repos by default: todo by maintainer once appropriate
- Tracker bug: #2319402
- Release notes tracker: <will be assigned by the Wrangler>
Expected schedule
- Eclipse Temurin repositories already exists: https://adoptium.net/installation/linux/#_centosrhelfedora_instructions
- RPMs can be easily integrated. Remaining issues are summed up at: https://github.com/adoptium/installer/issues/848 ; but they do not block immediate usage
- RPM with repository on review: https://bugzilla.redhat.com/show_bug.cgi?id=2313339
- JDKs will be obsoleted from f42 onwards only. The Repository may be available also for older Fedoras, as they can coexists.
- to keep en system-jdk idea as it is, the requires of "java", "java-devel" and "java-headless" were revisited
- those will be encapsulated them to "javapackages-tools" and "javapavckages-local" which handles system JDK anyway in user independent way (https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_java_command_setting#Summary)
- the documentation of https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/#_buildrequires_and_requires will be updated
- all non-system LTS JDKs will be orphaned or replaced by obsoleting package with possible dependency on the repository wrapper)
As 'Change Checkpoint: Proposal submission deadline (System Wide Changes) Tue 2024-12-24' and 'Branch Fedora Linux 42 from Rawhide Tue 2025-02-04' is in reasonable time, we hope to finish all peacefully (as all initial tests are already finished).
Detailed Description
Fedora currently ships:
- java-1.8.0-openjdk (LTS)
- java-11-openjdk (LTS)
- java-17-openjdk (LTS)
- java-21-openjdk (LTS), system JDK
- java-latest-openjdk (STS) - currently JDK22, soon JDK23, in time of finish JDK24
- In future, java-25-openjdk (LTS) will fork from java-latest-openjdk, and will become system jdk, as jdk21 before (https://fedoraproject.org/wiki/Changes/Java21#java-21-openjdk_as_the_system_JDK_in_F40) and jdk17 before that and so on...
- java-21-openjdk will then follow the fate of java-17-openjdk, 11 and 1.8.0 as written lower.
We, OpenJDK maintainers in Fedora, would like to orphan/retire non system JDKs in favor of Temurin JDKs. Adoptium Temurin (https://adoptium.net/temurin/releases/) is de-facto standard build of JDK, with huge support and compatibility, and all current Fedora JDK contributors are long term members and contributors to Temrun JDK (and its RPMs). Adoptium is dedicated, to keep Temurin RPMs well integrated and healthy for Fedora. Adoptium efforts are tracked in https://github.com/adoptium/installer/issues/848 . Adoptium is maintaining theirs repos (https://adoptium.net/installation/linux/#_centosrhelfedora_instructions) for ages, and they're heavily used.
Practically We see several approaches:
- simply orphan jdk 8,11 and 17 (in time of f42 the only system JDK will be 21 over all live fedoras)
- However past (orphaning of jdk 6 and 7 ) had learned us a lesson that avarage packager (despite being experienced java/C programmer) is unable to maintain OpenJDK packages
- note that it means, that the packages would be orphaned also in older fedoras
- orphan (including the orphaning in f40+f41) or retire in f42++
- enhance https://docs.fedoraproject.org/en-US/quick-docs/installing-java/ that non system JDK can be installed after enabling the adoptium repos (https://adoptium.net/installation/linux/#_centosrhelfedora_instructions)
- orphan (including the orphaning in f40+f41) or retire in f42++
- provide rpm which will contain the 3d party repository
- enhance https://docs.fedoraproject.org/en-US/quick-docs/installing-java/ informing about that
- orphan (including the orphaning in f40+f41) or retire in f42++
- provide rpm which will contain the 3d party repository\
- enhance https://docs.fedoraproject.org/en-US/quick-docs/
- orphan (including the orphaning in f40+f41) or retire in f42++
- provide rpm which will contain the 3d party repository
obsolate
will be handled via the above repository rpm- integrate it with gnome software and and fedora setup of 3rd party repos
- we would like try to do an fluent transition - so the current 8,11 and 17 packages will also install the rpm wiht repository files and thus once we remove jdk8-17 (or future) from distribution, they will be smoothly updated by temurin jdk (with check if other 3rd party repos are enabled)
- not sure if this technically possible nor correct
I'm voting for option 5, without the hard 5.4 requirement (so worthy to try, but not not invasivly nor mandatory)
java-latest-openjdk remain also maintained in Koji, as it is necessary testing ground for future system JDK.
It was never an intention to repack a binary Temurin blob in Koji (just in case anybody will think about it). It is not an intention to get rid of maintaining System JDK. However once JDK will no longer be System jdk in any live Fedora, it will be orphaned/closed in favor of Temurin JDK. So once f42 will go out we will continue to maintain only jdk 23+21. In some short time, we will maintain 25+21, a bit alter 26+25+21... And once 25 will become system JDK in all live fedoras, we will ditch 21 in favor of Temurins
java packages requires
mass change
The javastack (via javapackages-tools) will be reworked to:
- encapsulate dependencies on system jdk (or any other koji-based jdk) to javapackages tools
- allow any application to work on any, even 3rd party java
This should be achieved via following chnages to reqires changes and generated changes:
javapackages-local
for packages withant
or no build -requires java-%{system}-openjdk-devel
(%jpackage_script
)javapavckages-local%VERSIONED
for older ones- For slower transitions to newer jdks
javapackages-tools
requires java-%{system}-openjdk-headless
javapackages-tools%VERSIONED
for older ones- Do not requires java-%{system}-openjdk
- Will not be added - satisfied by Javapackages-tools with java || java-xyz-openjdk requires
- Requires generator which crawls through launchers of packages (including
jpackage_script
) which sourcejava_functions
- will be pointing to used jre headless
%jpackage_script
is implicitly affected by generator and will generate requires to corresponding%{build_time_sdk's}-headless jre
(which is currently system jdk, which is jdl 21, unless specified differently)
- Other packages will need to manually adjust from
java-%{system}-openjdk-/headless/devel
tojava-(system+1)-openjdk-/headless/devel
- This affects mass rebuilds (instead of just release++ a java-xy-openjdk must do xy++). Positive si that there is more time to do that
- Indirectly this is not enforcing new system jdk when new LTS is promoted in Fedora
- Otherwise generic
java-devel
will no longer satisfy new systemjdk after system bump
- Otherwise generic
JAVA_HOME
remains main override (rpm generated requires are not affected (maybe todo?))
https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/ will be adjusted accordingly
the packages built by pure javac or jsut build requires java without any javapackages tools will be adjsuted manually
Note, that this is much smaller effort then it looks like. 99% of packages are living with generated provides, and will get the change automagically. The remaining - aprox 10 - packages will be handled manually
adoptium-temurin-java-repository
- the adoptium repository is provided via adoptium-temurin-java-repository package
- This package is available since f39 over epel 8 and 9 up to future. Since f42 it will be obsoleting retired java-(1.8.0,11,17)-openjdk-*
- repository is disabled by default
- can be enabled by gnome-software or via its repo file
- installs:
- temurin-11-jdk
- temurin-11-jre
- temurin-17-jdk
- temurin-17-jre
- temurin-21-jdk
- temurin-21-jre
- temurin-22-jdk
- temurin-22-jre
- temurin-23-jdk
- temurin-23-jre
- temurin-8-jdk
- temurin-8-jre
- Warning, jdk contains both jre and jdk, so if you install jdk and jre (of same version) you will have two java alternatives masters, and one javac master.
sudo dnf install adoptium-temurin-java-repository
Feedback
todo
Benefit to Fedora
The number of legacy JDKs have grown, and hand in hand with that the number of theirs usages dropped to minimum. It seems there is no longer any need to maintain them, as theirs usage is only highly specialized.
By providing 3rd party repo, we allow the specialized use-cases to continue to exist. By discontinuing theirs build in koji we well untie or hands to move forward and focus on future JDKs. Also we will enable fedora to provide highly stable, often updated, secure, 100% integrate-able and passionately maintained builds of legacy JDKs, which will serve as proper replacement if really needed. As a side effect of the changes in provides/requires
, we will allow every JDK, from any vendor, which follows unofficial packaging JEP (which covers java and javac alternatives master and java/java-devel provides) to be effectively part of system if wanted, and not just silent companion.
More time for pacakges to react to new LTS
Another positive is more time for packages to adapt and/or die faster. Currently, if package was unable to adjsut to new system JDK, the package was moved to require exactly one, versioned, known newest java it worked with. And so it very often went rotten. Now, if new LTS is introduced, the package will still work with the previous one, until the owner decides to really move on. If not, then this package will die by its own in *one year*, when "it's" jdk will be removed from fedora
Scope
- Proposal owners:
- will provide and maintain the 3rd party repo - https://bugzilla.redhat.com/show_bug.cgi?id=2313339
- will help to integrate it with gnome-software and other 3rd party repos units
- will orphan or replace (based on agreement on
details
- will update java packages documentation
- we will fix all the direct requires java/java-devel (aprox 14 only)
- we will communicate with packagers of known, remainingm packages which do not run with system jdk (aprox 5 )
- Other developers:
- javapackages-tools, maven and ant maintainers are already on board to to totally decuple system jdk from installed java
- Release engineering: #Releng issue number
- I think the mass rebuild will not be needed
- Policies and guidelines: N/A (not needed for this Change)
- java packaging guidelines will be updated
- Trademark approval: N/A (not needed for this Change)
- Alignment with the Fedora Strategy:
- This proposal is aligned with Fedora mission - to be on top of technology. We want to focus on newer JDKs, and still provide comfortable access to legacy ones,
Upgrade/compatibility impact
No meter what approach will be selected at the end, there will be upgrade impact.
- in ideal usecase, the JDKs from koji simply replaces themselves by those from Eclipse Temurin
- in worst case, user will just get disabled 3rd party repo and updated docs.
In all cases system jdk will remain on machine, and in all cases legacy jdks will be replaced or disappear. I would really be unhappy to simply discontinue them, and leave unmaintained software on target boxes.
Early Testing (Optional)
Do you require 'QA Blueprint' support? Y
How To Test
No JDK on system
- get system without java
- update to next fedora
- no JDK should be there
Only system JDK on system and future STS jdk
- get system with system jdk only
- update to next fedora
- JDK should be there
Only legacy JDK
- get system withotu any JDK
- manually install any of legacy LTS jdks
- update to next fedora
- the legacy jdk should not be there or should be gone
System JDK and legacy JDK
- get system with system jdk only
- manually install any of legacy LTS jdks
- update to next fedora
- system JDK should be there
- the legacy jdk should not be there or should be gone
Minecraft
There were concerns in discussion thread, that Minecraft may have issues to run, or to be modded. This usecase is valuable, and I would like to prevent any loses on fedora Minecraft community.
User Experience
As already described, basic users should not notice change. Advanced users should not lost.
Dependencies
Several (less then 10) packages will lost theirs main dependencies. Those list will be enumerated. Those packages will need to orphan and move to different kind of distribution or update. Main java stack - the packages depending on system java/java-devel/java-headless/java-packages-tools and similar, should not notice change.
Contingency Plan
- Contingency mechanism: If we fails to introduce Eclipse Temurin JDKs repo, we will simply orphan legacy JDKs as written earlier
- Contingency deadline: 1. December 2024
- Blocks release? Yes
Documentation
Only eclipse temurin install pages and java packages guidelines
- todo link1
- todo link2
...
The content of the changes to guidelines will be mostly based on https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks#java_packages_requires_mass_change
Release Notes
From user point of view, not that much should chage. Based on the result of https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks#Detailed_Description users will be informed:
- java 8,11 and 17 are gone
- they are maybe replaced by temurins
- they temurisn are maybe enabled by default
- in all cases temurins can be used
- how
- the feature is forward rolling, and once LTS jdk wills top being system jdk, it will drift to temurins too.