F43 Change Proposal: java25 and no more system JDK (system-wide)

Project Discussion Change Proposals
,
1

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.

Wiki
Announced

:link: Summary

Add java-25-openjdk with non blocking mass bump and rebuild.

:link: Owner

:link: 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 Changes/ThirdPartyLegacyJdks - Fedora Project Wiki). 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 Changes/ThirdPartyLegacyJdks - Fedora Project Wiki - 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 Java Packaging Guidelines :: Fedora Docs 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 Changes/ThirdPartyLegacyJdks - Fedora Project Wiki, 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).

:link: 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 - Issue #3362: jdk25 as system jdk in f43 - can branching of f43 be delayed by week or (better) two? - fesco - Pagure.io
    • 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

:link: Feedback

todo

:link: 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. JDK 25 JDK 24 JDK 23 JDK 22

:link: 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 Changes/ThirdPartyLegacyJdks - Fedora Project Wiki 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

:link: Upgrade/compatibility impact

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

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? Y/N

:link: How To Test

todo

:link: 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.

:link: Dependencies

:link: 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

:link: Documentation

:link: common issues packagers can face and gathered solutions

:link: Removed SecurityManager

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

:link: Release Notes

Last edited by @amoloney 2025-03-19T18:39:25Z

Last edited by @amoloney 2025-03-19T18:39:25Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

When will we be able to make java-25-openjdk the one-and-only in ELN, where we generally have had only the latest LTS?

4

I don’t understand: if you dnf install java in F43/F44, what will be installed?

5

Hi! TBH, I was not not thinking about ELN at all. In epels there is only java-latest-openjdk, which will never provide java. For ELN, which is built from fedora, I think the “new” state, where more jdks can provide java is appropriate way to go on. All packages will alter or sooner adjsut, and ELN will inherit this changes. If issues arise, we will need to elaborate.

6

Hi! It will pull whatever dnf transaction will resolve. You can be always more specific what exact jdk you want, but if you are not installing simply “java”, the dnf is doing usually pretty good job - some of the dependencies will pull the trigger and narrow the jdk selection to some exact version. If more JDKs will be required, then both will end in transaction.

Just side note to your exact example - dnf install java, in case you already have jre-X, will download jdk-X, not JDK-y.

One more note, dnf is pretty clear what to install if more providers exists - It is indeterministic If you look into the sources ( I last did some 5 years ago), the shorter name would win. If both names are of same length, then I’m afraid it is back on indeterministic (as per dnf docs).

7

Could there be any impacts between packages that use one or the other java?

ie, if packageA uses java25, but packageB doesn’t build, so uses java21, but packageB also needs packageA to build and they are mismatched?

so, would it need to be stacks of things all moved at once? Or does this not matter much in the java ecosystem?

8

hi! This was probably the most thought-through part. In past releases, aprox 70% of necessary patching of sources, was source/target, which had direct, unpleasant, consequences. In case of reflection, those were found in runtime, not in compile time. We (mostly me and MIkolai) would like to get rid of this patching with idea of “upstream knows better”. this was not possible before jdk 17, where changes between jdks were quite dramatical, but is possible now.
Another lesson we learned is, that upstreams are usually keeping lowest possible source/target intentionally and together with it are keeping peace with modern java features and thus keeping quite nice balance.

In down stream, the logic which is already there is, that javapackages-tools, if used properly (which through maven usually is) are setting up runtime JDK correctly (by oldest by dependence chain)

To your highlighted use case - that may happen. But it is really really unlikely. due to reasons above. From what I saw when walking through packages, all seems to be jdk21 compatible even if built by jdk25. And if build by jdk25, and run by both is ok, then your usecase is implicitly ok. If there will be corner case, it will be act one by one.

I wrote slightly longer then I originaly wanted, but hope that explains. TY!!

9

ok, fair enough. I just wanted to know that it was considered and the risk was low enough. :slight_smile:

1 Like
10

I have some questions regarding this plan.

  1. I am a bit confused by “no more system JDK”. Reading the proposal, the effect would be “two system JDKs” (at least temporarily), not “no more system JDK”?
  2. I wonder if it’s a good idea to have the default for building packages be OpenJDK 21 while the default for running stuff would be OpenJDK 25? Or am I misunderstanding something?
  3. How will upgrades from earlier Fedora versions be handled? They will have OpenJDK 21 installed before the upgrade. Will that be replaced with OpenJDK 25 on upgrade? I think this should be the case, since fresh installs will apparently get OpenJDK 25 too.
11

Hi!

Nope. really it means no system JDK. By default there will be two jdks providing java, which is “the” provide. Anything providing java will be treated equally. The driver of this change is as described - every jdk out there is providing java - or better is following the jpackage provides (which also means exact version/flavor may be obtained) The system concept JDK did its job over the dramatic changes from jdk8 to 17, but now it should return to universal jdk ability as described in original java-packages.

the default built jdk21 remains only as temporary fallback. Each package should be explicit what jdk it wish to build with, and which to run with. The second should be already as it - explicit. the first fallback to jdk21, but in case of 25->29 the fallback should no longer be there. We will try to bump each package with version-less requires to build by 25, and if it do not work, the fix will be to revert to version-full requires of jdk21.

that will depend on dnf transaction, isn’t it (feel free to cottect me)? In “worst” case user will have both jdk21 and 25 - and I think it will be quite common. Thats why worst is in quotes, as it is more normal then worst.

just imagine jdks on old → before install → after install → jdks on newsystem
jdk21 → appA req java → appA req. jdk25 → jdk25
jdk21 → appB req java → appB req. jdk21 → jdk21
jdk21 → appA req java, appB req java - >appA req. jdk25,appB req. jdk21 → jdk21 and jdk25

hope that explains,
J.

12

Wait, does this mean that all Java packages in Fedora need to be adjusted every time the JDK changes? That seems like a massive waste of time …

It doesn’t depend on the DNF transaction, it depends on how the package metadata (RPM Provides / Obsoletes, etc.) and / or “alternatives” are set up?

And if both jdk21 and jdk25 “provide java”, as you said, I would assume that they’re not co-installable? Or if they are, which one will end up providing /usr/bin/java etc.?

13

Not exactly. You can stay to live with generic java requirement, which will give you some “java”. If you do not want that (which is probably most of packages) then you really must be explicit on what jdk to use, and if you want to bump it, you have to elaborate.
However, the main benefit is the removal of mandatory mass rebuilds. Until now, when new system jdk landed, everything had to be adjusted. True, I did not need to edit the requires, but I had to look in why it fails, and fix or rebase, or report bug.
Now, I need to edit the requires, but except that, it gives me anther year and half time, to adjust to new system jdk if it goes wrong, and no rush hacking is necessary.

Maybe you know better then me, but as I see it, no Obsoletes would help. Both jdks which will remain in fedora should be treated equally.
Alternatives have absolutely nothing to do with this.

They are, and must stay co-installable. /usr/bin/java etc are subject of alternatives. If yoare using it, the jdk which will be picked up depends on alternatives. If those will be in auto, jdk25 will ahve higher priority. However correct launchers are using jpackage sctripts, which are independent on alternatives, and are pointing to the correct java your package reqires.

hth. Thanx for the questions, highly appreciated.

14

This change proposal has now been submitted to FESCo with ticket #3385 for voting.

To find out more, please visit our Changes Policy documentation.