From Fedora Project Wiki


πŸ”— java-25-openjdk as preferred JDK in F43 and lost 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 with non blocking mass bump and rebuild.

πŸ”— Owner


πŸ”— Current status

  • Targeted release: Fedora Linux 43
  • Last updated: 2025-03-13
  • [<link to devel-announce post will be added by Wrangler> Announced]
  • [<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>

πŸ”— Detailed Description

JDK 25 will be released in September 2025, and will most likely become a LTS JDK. It will be added to all live Fedoras, however in f43 and higher, it will 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.

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. We will do a mass-rebuild, where we will try to build every java package by jdk25, but if they fallback, they will immediately roll back to jdk21, with 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 he 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 being transparent as JDK21 requirement, 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 remain
    • 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

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 disappear from Fedora and will be recommended to be replaced by Temurin by losing its status of "system jdk" in any live Fedora (so JDK21 should no longer be available in f45).

πŸ”— Schedule

  • 18.7.2025 Oracle CPU unembargo date
  • approx. 24.7 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 java-latest-openjdk will become jdk25
    • ideally immediately after CPU.
  • no later then 8.8. java-25-openjdk will be forked and used in rawhide
    • ideally immediately after CPU.
    • mass rebuild right after it
  • fedora branching 12.8.2025 - https://pagure.io/fesco/issue/3362
    • no exception it seems
  • 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

todo

πŸ”— 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.

πŸ”— 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