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.

15

Fedora 43 Java Change Proposal – overview by mizdebsk

This is my attempt to provide a higher-level overview of the proposed change, with a focus on clarifying aspects that were not clear in the original proposal. The following description conveys essentially the same idea but in a different way, aiming to make it easier to understand for those unfamiliar with the details of Java packaging in Fedora.

Glossary

  • Java – A programming language and platform.
  • OpenJDK – An open-source implementation of Java, typically packaged as java-$x-openjdk.
  • LTS OpenJDK – Long-Term Support versions of OpenJDK, maintained upstream for extended periods. Packaged as java-$version-openjdk.
  • STS OpenJDK – Short-Term Support versions of OpenJDK, maintained upstream for around 6 months until the next major release. In Fedora packaged as java-latest-openjdk rolling release package, updated to latest versions as they are released upstream.
  • Java package – A Fedora RPM package containing Java code compiled from source.
  • Java application – A Java package designed for end users. It includes a launcher in /usr/bin.
  • Java library – A Java package that is not a standalone application. It provides only JAR files and is intended to be used as a dependency in other Java applications.
  • Java SIG – An informal group of contributors interested in Java in Fedora. We don’t hold formal meetings or use a dedicated Matrix room, but we actively collaborate to deliver a great Java experience in Fedora.

Compatibility

Java is renowned for its exceptional backward compatibility. Applications compiled decades ago can still run on modern Java runtimes, with no compromise in performance or security—thanks to Just-In-Time (JIT) compilation.

The reverse is also possible: Java code can run on older JDKs if compiled with the --release flag, which is a very common practice.

This flexibility allows Fedora to ship packages built with different Java versions, all working seamlessly together. There is no need for version-specific package duplication.

Additionally, users can run applications using a different Java runtime than the one used to build them. For example, Fedora-packaged applications can run with Adoptium JDKs from third-party repositories.

Status in Fedora 41 and Earlier

  • Multiple LTS versions of OpenJDK were packaged.
  • One version was designated the “system Java.”
  • Switching the system Java required a FESCo-approved change and coordinated porting by the Java SIG.

Status in Fedora 42

  • Only one OpenJDK LTS version (OpenJDK 21) is packaged.
  • OpenJDK 21 is the de facto “system JDK” due to lack of alternatives.
  • Some may argue there is no “system JDK” because there is no choice.

Proposed Change for Fedora 43

  • Introduce another LTS version—OpenJDK 25—alongside OpenJDK 21.
  • Treat both LTS versions equally; neither is the default.
  • Users and maintainers can choose which version to use.
  • The most recent version will likely become the conventionally preferred one, but this is not enforced.

What This Change Means for Fedora Users

  • Greater flexibility in selecting the Java runtime.
  • Freedom to mix and match Java versions for development and runtime.
  • Ability to use Fedora Java packages with third-party JDKs.

What This Means for Java Package Maintainers

  • Packages built with OpenJDK 21 will remain on 21 until maintainers opt to migrate to OpenJDK 25.
  • Migration can proceed gradually over multiple Fedora releases.
  • Java SIG may assist in migrating packages when needed.
  • Bugs will be filed for packages that are hard to migrate.
  • Provenpackagers may fix some issues if maintainers are unresponsive.
  • Unmaintained packages may be retired when their Java version is retired.

Key Benefit: Unported packages will no longer block the adoption of new Java versions. Updates will proceed more smoothly, and the Java SIG will no longer have to carry the burden of mass migration efforts alone.

Runtime Strategies for Java Applications

Java applications in Fedora can follow one of these approaches:

  1. Generic Java dependency
    Use a generic “java” dependency – This allows compatibility with any implementation, including third-party JDKs. The actual runtime is chosen based on available repositories and system alternatives.
    Examples: Tomcat, LibreOffice

  2. Specific OpenJDK version dependency
    The application uses only the specified OpenJDK version. Third-party JDKs or alternatives configuration won’t affect it.
    Examples: JFlex, CUP

  3. Version-specific subpackages
    Offers bindings for multiple Java versions; users choose the one they need.
    Examples: Maven, Ant

Application maintainers know their software best and can choose the strategy that aligns with their users’ needs.

Note: Java library packages are not affected by these runtime concerns, as they do not depend on any Java runtime.

16

Treat both LTS versions equally; neither is the default.

That is in direct contradiction with even the title of the Change proposal:

java-25-openjdk as preferred JDK in F43

All in all, I think the Change Proposal is just written in a way that is very detailed but at the same time just too getting lost in the details, making it easy to miss the important things (at least for me):

  1. I wouldn’t mention the term “system JDK” at all.

It just confused me - and there doesn’t really actually seem to be a change from the status quo (one LTS version will be the preferred one, and it will be v25 in Fedora 43, whereas it was v21 in Fedora 42).

The title of the Wiki page is even contradictory here: " java-25-openjdk as preferred JDK in F43 and lost of concept of system JDK"

Well what is it? Is there a preferred one or not? :smiley:

  1. I would cut down the “detailed description” by ~90%.

Just mention that the default JDK for building packages will be java-25-openjdk instead of java-21-openjdk, and mention the actual new thing that packages can opt to build with the non-preferred version if needed.

I don’t think the minor details of what changes were made to javapackages-tools are actually interesting for readers of the Change Proposal. The actual changes needed in Packages need to be documented in the Packaging Guidelines, not in the Change document.

17

There is no contradiction.

The Change proposal sets a preference, not a mandate, which is fully in line with Fedora’s general strategy of favoring the latest and greatest technologies. While the Change proposal recommends java-25-openjdk as the preferred JDK in F43, both java-21-openjdk and java-25-openjdk will be packaged equally, and the tooling will fully support building packages with either version.

In other words, both versions are treated the same from a technical and packaging standpoint. The preference for Java 25 is a recommendation—not a requirement—for packagers to adopt the newer version when it makes sense for their use cases.

For example, I plan to move Maven, Ant, and other packages I maintain to Java 25 (and in fact I have all the necessary changes already prepared, just not pushed out yet), but that’s outside the scope of the Change itself and remains an individual maintainer’s choice.

Importantly, as part of the Change we are not changing any defaults. Packages that are currently built with Java 21 will continue to do so unless individual maintainers explicitly choose to switch to Java 25. Any broader transition would require a coordinated effort through a system-wide change, which is not part of this proposal due to tight timelines (see FESCo issue 3362). That said, such Change proposal is not unlikely for Fedora 44 in the future.

Does that clarify things?

18

I had mentioned, that I will run the mass rebuild, and will try to move packages to jdk25. If it fails, the fall back is simply go back to jdk21. The main reason for this is to move to versioned java-packages-tools/ant/maven… calls. That includes also the “revert” to jdk21. From versionless, versin-full. It is written in proposal.

@mizdebsk, is it ok by you?

@decathorpe Where I practically agree with you, the information here are important. based on them, I will base the mass rebuild, and on them, I will base the changes to java-packaging guidelines. As this is system wide change, and the mass rebuild and changes to javapackaging-guidelines are based on them, I considered as necessary, to make primary readers - fesco, the approving argument - aware of them and sure of them. The changes to packages and the chages to guidelines are done later, without much more people looking into them (from technical correctness view), so

If you do not like the verbose version, which is covering both philosophical and technical aspects, then I would need to scratch it - eg repalce it by content Mikolaj wrote - and jsut link this originnal one as “tehcnical details” . wdyt?

I will start to work on simplifcation with pboy, but am not sure how much technical details will disapear at the end

Up to now, we have not found a single issue in the proposal, except it being to long and to detailed. I’m reading your complains, and am trying to somehow fix that, but the only solution I see is to move some of the details to some subsection of “technical details”, so the minline will be more stirghtforward. wdyt?

19

I think clarifying the main points (and clearing up what you both want from this change proposal - it looks like you’re not agreeing on everything amongst yourselves at this point) would be great.

The detailed description is already under the “Detailed description” heading so that’s fine, I guess.

20

In the summary a link has been added:

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

But it is broken.
Also, I think it would be much better to have a clear description (or summary) in the change proposal, not in an external link that might brake in the future and make it hard to understand things in a few years