From Fedora Project Wiki
Line 152: Line 152:
* 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?-->
** will provide and maintain the 3rd party repo
** 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 help to integrate it with gnome-software and other 3rd party repos units
** will orphan or replace (based on agreement on `details`
** will orphan or replace (based on agreement on `details`

Revision as of 15:38, 18 September 2024

Guidance
For details on how to fill out this form, see the documentation.


Adjust java/java-devel requires to multi-vendor JDK world and replace legacy JDKs by third party Eclipse Temurin repositories

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

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


Current status

  • Targeted release: Fedora Linux 42
  • Last updated: 2024-09-18
  • Writing in progress
  • [<will be assigned by the Wrangler> Discussion thread]
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Expected schedule

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

JDK TEAM NOTE:
in el10 there is only one jdk, however, the non binding java/java-devel, and all the whole "system jdk in javapackages-tools" is quite a precedent for it, and considering we will be updating system jdk in el aprox 3x, we should take exceptional care here, as it may solve - or bite back - the issue we are facin gin el9 now

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 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/close 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 f42 the only system JDK will be 21)
    • 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
  • orphan the packages and close them. 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)
  • provide rpm which will contain the 3d party repository\
    • 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)

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

In original draft, we had an intention to remove versionless (eg java, javac, java-devel..) from Eclipse Temurin JRE/JDK, however we found that it would be exceptionally negative step considering current state of java. Many vendors - from Oracle, over Azul, Red Hat, Amazon to Eclipse Adptium, offers 3rd party repositories with theirs javas, or at least place to download binaries - including rpms - and all of them provides at least java, and most of them also javac and java-devel. We get inspiration from https://fedoraproject.org/wiki/Changes/Drop_Mandatory_Requires_on_JRE and we would like to gain an advantage from all this. Thus java, and java-devel will remain global requires, which will be satisfied by any LTS java.
below section will be dropped
To keep an system JDK concept as we have it now, we would like to replace mandatory requires on java/java-devel by javapackaes-tools(-headless,-devel). Except aligning with above java/javac "globally available provides" and "dropping of mandatory requirements", most of the java packages do not require java/javac. They already require javapackages-tools, for runtime, and maven/ant (or similar) for buildtime, so this change will affect only 14 from aprox. 400 packages we mass rebuild during system JDK bump. Those will be fixed manually. Not sure if this can be considered mass rebuild.

and replaced by resutls of meeting with javasig members:
FIXME: It seems that not that much playing with provides is necessary

  • https://issues.redhat.com/browse/RHEL-54070
    • Decouple javastack to run with any jdk - even not rpm ones
  • Javapackages-local for packages with ant and no build - requires java-system-openjdk-devel (%jpackage_script)
    • Javapavckages-local%VERSIONED for older ones
  • Headless jpackage script currently do not support headless. Will be worthy to do
    • java-sig is already on that
    • %jpackage_script macro goes with requires to system jdk too

Other packages will need to manually adjust from java-system-openjdk-/headless/devel to java-(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 (as much time as the latest jdk is kept, that is while it is system jdk in some fedora, that measn 2-3 releases

  • Runtime requires:
    • Jpackage script dependency generator should generate them, otherwise use versioned java
  • Versioned -local packages?
    • Not a good practise
  • What about non-RPM Java?
    • Will work it out per package

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.

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:
    • we will need help from javapackages-tools, maven and ant maintainers, to totally decuple system jdk from installed java
  • 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

  1. get system without java
  2. update to next fedora
  3. no JDK should be there

Only system JDK on system and future STS jdk

  1. get system with system jdk only
  2. update to next fedora
  3. JDK should be there

Only legacy JDK

  1. get system withotu any JDK
  2. manually install any of legacy LTS jdks
  3. update to next fedora
  4. the legacy jdk should not be there or should be gone

System JDK and legacy JDK

  1. get system with system jdk only
  2. manually install any of legacy LTS jdks
  3. update to next fedora
  4. system JDK should be there
  5. the legacy jdk should not be there or should be gone


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

Release Notes

tbd

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