Changes/Java25AndNoMoreSystemJdk

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

• Name: Jiri Vanek
• Email: jvanek@redhat.com

Current status

• Targeted release: Fedora Linux 43
• Last updated: 2025-03-07
• [<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 stay LTS. It will be added to all live Fedoras, however in f43 and up, it will provide "java". Note, that in f43 and f44, there will still be JDK21, and it will continue to provide "java". java-latest-openjdk will continue to never provide "java", and will 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: That really means, that in f43+f44 there will be two JDKs providing java. That is intentional, and it is unpredicted consequence of https://fedoraproject.org/wiki/Changes/ThirdPartyLegacyJdks - because every 3rd party jdk, is providing java. Maven and Ant tools had adapted to this schema already in life-time of f41 and f42.

This is conceptually removing the need of mass rebuild, because any package in f43 will continue 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... which's versionless requires still requires jdk21, but have also version-full requires. Those version-full requires are recommended to be used, so packager is clear what JDK 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 reqires, 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.

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

Any package can decide to stay on any (available) JDK version, while it is in system, so if there is major breakage for them, they have more then 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
• cca 24.7 Oracle CPU reaches Fedora (hopefully stable)
  • jdk25 must go to fedora as EA (because of 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 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.

• Release engineering: #Releng issue number

• 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 asap as expected, and all java packages should remain fully operational.

Dependencies

Whole javastack will be affected and walked through as much as possible.

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.

• jdk24 jep: https://openjdk.org/jeps/486