From Fedora Project Wiki


java-25-openjdk as preferred JDK in F43 and removal of concept of system JDK

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

Add java-25-openjdk to fedora, but do not FTBS if the package fails to build during mass rebuild. Such package will be moved to java-21-openjdk

See a nice complementary summary: https://github.com/judovana/java25-change/blob/main/README.md

Owner


Current status

Description

  • in f43, java-25-openjdk will be added
  • in f43, java-21-openjdk will continue to exist
  • both java-21-openjdk and java-25-opendjk will continue to coexists in parallel, and will be considered equal.
  • this will give packagers more time to migrate from java-21-openjdk to java-25-openjdk
  • mass rebuild with java-25-openjdk will happen, but what will fail, will simply revert back to java-21-openjdk
    • with changed, jdk21 targeting, requires
  • for technical details see #Detailed_Description and onwards

Detailed Description

JDK 25 will be released in September 2025, and will most likely become a LTS JDK in upsteam. It will be added to Fedora as java-25-openjdk. It will be added to all live Fedoras, however in f43 and higher, it will provide java. In f42 and f41 it will not provide java. Note, that in f43 and f44, there still will be JDK21, and it will continue to provide java. java-latest-openjdk won't be providing java as usual, and it will be bumped to JDK26 as soon as possible. JDK21 will remain in Fedoras, until it is newest JDK providing java in any live Fedora (f44) - as described in https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks). Highlight - the JDK21 will no longer be present in f45.

Highlight: In practice, this means that in f43 and f44, there will be two JDKs (JDK21 and JDK25) providing java. That is intentional, and it is unexpected consequence of https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks - because every third-party JDK is providing java. Maven and Ant tools has adapted to this schema already during the life-time of f41 and f42.

Summing-up:

  • In f41+f42, jdk21 will provide java, but JDK-25 will not - so JDK-21 is the newest OpenJDK providing java
  • in f43 and f44 JDK-21 and 25 are both providing java, so jdk 25 is newest JDK providing java, not JDK-2121.
  • in the moment f42 dies, jdk21 "as newest with java provides" dies. That is in time of f44 - the last fedora with jdk21.
  • if this works as expected, this should repeat with jdk29

In Fedora 43 & 44, both java-21-openjdk and java-25-openjdk will provide "java. This differs from the introduction of previous JDKs where the previous version immediately stopped providing 'java'. This is intentional and is now possible thanks to the work done to allow the use of 3rd party JDKs which also provide java.

This is conceptually removing the need of mass rebuild, because any package in f43 will be built by JDK21 as they are now, and maintainers will have more then year and half to migrate to JDK25.

This reduces the need for a mass rebuild as every package in Fedora 43 & 44 will continue to be built with java-21-openjdk by default. We will attempt a mass rebuild using java-25-openjdk, but any packages that fail will be rolled back to java-21-openjdk and the maintainer notified.

This transparency is handled in javapackages-tools/maven/ant... whose versionless requires still require JDK21, but have also version-full requires. Those version-full requires are recommended to be used, so packager is clear what JDK they wants to pull. My approach for mass rebuild will be bump to current version-less requires version-full - JDK25 - requires. If build fails, the "revert" will go to version-full - JDK21 requires, not to version-less. The https://docs.fedoraproject.org/en-US/packaging-guidelines/Java/ will need adjusting.

The version-less provides are being transparent as JDK21 requirement. This should remain as it is, and will die on its own with removal of jdk21.

Enumerations:

  • javapackages-local-openjdk21 - requires java-21-openjdk-devel and in addition provides javapackages-local
  • javapackages-local requires javapackages-local-openjdk21 and will die with it.
  • javapackages-local-openjdk25 - requires java-25-openjdk-devel and provides only javapackages-local-openjdk25

Same for ant and maven-local:

  • maven-local is alias for maven-local-openjdk21, and it will be removed with removal of JDK21 too.
    • further packages should require maven-local-openjdkXY
    • maven-local-openjdk21 for "legacy" and maven-local-openjdk25 for future
  • ant suggests ant-local-openjdk21
    • once jdk25 is out, it should change (in rawhide/sine f43) to ant-local-openjdk25
    • ant should always be used together with javapackages-local-openjdkXYZ
    • without exact javapackages-local-openjdkXYZ ant is rolling reelase

Note, that maven and ant, without the -local suffix are not affected by any provides. But in case of ant, the -local-openjdkXY is there already.

The JDKs are now stable and have smooth update path from one LTS to another over STSs, and similar behavior should be the desired one.

Any packager can decide to keep any (available) JDK version, as long as it is in system, so if there is major breakage for them, they have more than a year to fix it. In scope of https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks, the JDK will be removed from Fedora and once it lost status of "system jdk" in any live Fedora (so JDK21 should no longer be available in f45, and will be deprecated in live f43+f44 in them moment of removal). For those who wish to continue using OpenJDK 21 after that time, the recommendation is to use the third party Temurin JDK 21"

Schedule

  • 15.7.2025 Oracle CPU unembargo date
  • approx. 24.7.2025 Oracle CPU reaches Fedora (hopefully stable)
    • JDK25 has to reach Fedora as EA (because of the early branching)
    • JDK may not need to be branched
    • mass rebuild must happen in July
  • no later then 31.7.2025 java-latest-openjdk will become jdk25
    • ideally immediately after CPU.
  • no later then 8.8.2025 java-25-openjdk will be forked and used in rawhide
    • ideally immediately after CPU unembargo.
    • mass rebuild right after it
  • fedora branching 12.8.2025 - https://pagure.io/fesco/issue/3362
    • there will be no exception to delay the f43 milestones
    • Instead, the latest EA candidate will be used
  • if mass rebuild will not happen, then the contingency plan is to go on without mass rebuild, just with devel announcement, and maybe do a mass rebuild in f44

Feedback

The proposal was found correct, but to much technical. I; author had failed to make it shorter. Thus starting the FAQ lower, to answer clearly all questions, which are to deep in the doc.

FAQ

  • Q: Both OpenJDK 21 and 25 will be available and considered “equal” ?
  • A: Indeed they will be considered as equal from all aspects. I do not see an aspect where they differ (except one being jdk21 and second 25)
  • Q: Really? OpenJDK 25 will have higher priority in alternatives
  • A: That was alway it. Newer JDK had always slightly higher priority in alternatives - except java-latest-openjdk. But Otherwise I agree with your statement that , OpenJDK 21 and 25 will be equal, but not really: But that is applicable probably everywhere where you update, and are trying to made the update transparent/compatible
  • Q: Really? OpenJDK 21 will have the versionless Provides!
  • A No.versionless provides will be in both jdk25 and 21. The provides which may confuse you are in maven bindings and javapackages-tools. When those used without explicit version, they will pull jdk21. Both java’s provides, when used without version and maven’s/javapackages-tool’s provides qithotu version, should be replaced to version full during mass rebuild
  • Q: No more mass rebuilds for Java updates will be necessary in future?
  • A: Indeed. each package will have an year to migrate onwards. Before, they were forced to update (by mass rebuild), and if it failed, they remained broken, and owner had to manually downgrade. That do not prohibit the mass rebuild - To try how much packages passes with next jdk, and if they pass, they will be updated. If not then there will be left - operational - on older jdk, and will have year to migrate
  • Q: But there will be a mass rebuild with OpenJDK 25 and only packages that fail will get modified to build with OpenJDK 21, implying that the default will be changed to v25.
  • Q: Doyou really mean **the** mass rebuild?
  • A: Yes, I really mean mass rebuild as it was during system jdk bump. Only except FTBS and failed package, there will be FTBS and working package, set to versioned jdk21 requires
  • A: Indeed. I would like to run mass rebuild. It is not mandatory thought. I have two reasons
    • one, lesser, to simply find how it is going. And if it is good, simply switch most packages to jdk25. By doing that, they will explicitly require 25.
    • second, bigger: what will not pass with jdk25, will go back to 21, will remain operational, but during downgrade, I will change the requires from versionless, to versionfull - on jdk21.
  • Q: Packages that don’t change will continue to get built with OpenJDK 21 - implying that indeed v21 will remain the default.
  • A: Nope. Each pkg will pull what it needs. If it (build)required 21, it will pull 21, if it (build)required 25, it will go with 25.
  • Q: How will this affect upgrades from earlier versions of Fedora?
  • A: In ideal world, only jdk25 will come in, in less ideal only jdk21, in worst, both. Depending on your java stack, and up to now unknown compatibility of jdk25 in real fedora world.
  • Q: Which one will be “preferred” based on alternatives priorities?
  • A: Alternatives have usually nothing to do with what jdk your application is using. If you are using generated launcher, then you will get correct, version-full path to the jdk you required. If you are using custom launcher, you are on your own. If you do not care, than you can use /usr/lib/jvm/java, or /bin/java(c) which are alternatives based. Or you can use version full, and align with your requires.
  • Q: Which one will be “preferred” based on alternatives priorities?
  • A: The jdk version is part of priority string, so jdk 25 will be preferred by alternatives in auto mode.
  • Q: How will this be handled on OSTree systems, where alternatives don’t work
  • A: They work, aprox since October 2024.
  • Q: if no action is taken, packages will build with OpenJDK 21
  • A: True. Packages which will be missed in mass rebuild. will remain on versionless provides and thus on jdk21. They will have year to adjust, and in f45 the versionelss provide, which was pointng to jdk21, will be removed togehter with jdk21.
  • Q: will build with OpenJDK 21 and the command line tools (i.e. /usr/bin/java and others) will be provided by OpenJDK 25
  • A: True. Several assumptions: It will be only few packages. From those few only really few will break in this setup.
  • Q:
  • A:

Benefit to Fedora

Fedora will stay on top with fresh technologies by having newest JDK available immediately and having new system JDK as soon as possible. Fedora will become multi-java friendly distribution, where each JDK vendor built will be correctly reusable. https://openjdk.org/projects/jdk/25/ https://openjdk.org/projects/jdk/24/ https://openjdk.org/projects/jdk/23/ https://openjdk.org/projects/jdk/22/

Scope

  • Proposal owners:

We will add JDK25 to Fedora, and will ensure, that it java provides are correct. That also means no java provides in f41 and f42

  • Other developers:

Maven and Ant stacks are already adapted thanx to https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks#adoptium-temurin-java-repository Other packagers may need to update packages to work fine with jdk25 or freeze their package to exact (21) version of JDK, and will have a year and half to fix theirs issues.

  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy: ok, I think

Upgrade/compatibility impact

User which was used to have exactly one - system - JDK, may end in having two.

states of java provides across Fedoras

  • f42 and older: jdk25 will be added, will coexist with jdk21 (and latest), and will not provide java
  • f43+f44 : jdk25 will be added, will coexist with jdk21 (and latest), and will provide java
  • f44 : jdk25 will be added, will coexist with java-latest, and will provide java. Jdk21 will no longer be there, and will disappear in same way as jdk8-17 did
    • so removed in f44 while early rawhide
    • together with that warning added to live branches
    • in rawhide, adoptium-temurin-java-repository will start to obsolete it

Early Testing (Optional)

Do you require 'QA Blueprint' support? Y/N

How To Test

todo

User Experience

Change should be transparent to all users and power users. Users will have latest JDK as soon as possible, as usual, and all Java packages should remain fully operational.


Dependencies

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) :
    • If it goes wrong, all packages will remain on JDK21. The JDK25 will stay there, and will also most likely still provide java
    • If the multiple java providing schema will case to work, the jdk21 java provides will be stripped off, and normal mass rebuild will happen.
  • Contingency deadline: beta freeze
  • Blocks release? No


Documentation

common issues packagers can face and gathered solutions

Removed SecurityManager

Any applications with security manager will need to explicitly stay on jdk21 or heavily update. SecurityManager is deprecated since JDK17.

Release Notes

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