F42 Change Proposal: Third Party Legacy JDKs (System-Wide)

Project Discussion Change Proposals
,
1

:link: Adjust java/java-devel requires to multi-vendor JDK world and replace legacy JDKs by third party Eclipse Temurin repositories

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.

Announced
Wiki

:link: Summary

Adjust java/java-devel provides/requires to multivendor world and obsolete all non-system LTS JDKs (java-1.8.0-openjdk, java-11-openjdk, java-17-openjdk in time of writing) by appropriate, properly integrating, RPMs from Eclipse Adoptium repositories.

:link: Owner

:link: Expected schedule

As ā€˜Change Checkpoint: Proposal submission deadline (System Wide Changes) Tue 2024-12-24ā€™ and ā€˜Branch Fedora Linux 42 from Rawhide Tue 2025-02-04ā€™ is in reasonable time, we hope to finish all peacefully (as all initial tests are already finished).

:link: Detailed Description

Fedora currently ships:

  • java-1.8.0-openjdk (LTS)
  • java-11-openjdk (LTS)
  • java-17-openjdk (LTS)
  • java-21-openjdk (LTS), system JDK
  • java-latest-openjdk (STS) - currently JDK22, soon JDK23, in time of finish JDK24
  • In future, java-25-openjdk will fork from java-latest-openjdk, and will become system jdk, as jdk21 before (Changes/Java21 - Fedora Project Wiki) and jdk17 before that and so onā€¦
    • java-21-openjdk will then follow the fate of java-17-openjdk, 11 and 1.8.0 as written lower.

We, OpenJDK maintainers in Fedora, would like to orphan/close/obsolete non system JDKs in favor of Temurin JDKs. Adoptium Temurin (https://adoptium.net/temurin/releases/) is de-facto standard build of JDK, with huge support and compatibility, and all current Fedora JDK contributors are long term members and contributors to Temrun JDK (and its RPMs). Adoptium is dedicated, to keep Temurin RPMs well integrated and healthy for Fedora. Adoptium efforts are tracked in adjust rpms and (maybe) repositories so Temurin JDKs can serve as replacement of non-system JDKs in Fedora Ā· Issue #848 Ā· adoptium/installer Ā· GitHub . Adoptium is maintaining theirs repos (https://adoptium.net/installation/linux/#_centosrhelfedora_instructions) for ages, and theyā€™re heavily used.

Practically We see several approaches:

  • simply orphan jdk 8,11 and 17 (in f42 the only system JDK will be 21)

    • However past (orphaning of jdk 6 and 7 ) had learned us a lesson that avarage packager (despite being experienced java/C programmer) is unable to maintain OpenJDK packages

  • orphan the packages and close them. enhance Installing Java :: Fedora Docs that non system JDK can be installed after enabling the adoptium repos (https://adoptium.net/installation/linux/#_centosrhelfedora_instructions)

  • orphan the packages and close them.

  • provide rpm which will contain the 3d party repository\

    • integrate it with gnome software and and fedora setup of 3rd party repos
    • we would like try to do an fluent transition - so the current 8,11 and 17 packages will also install the rpm wiht repository files and thus once we remove jdk8-17 (or future) from distribution, they will be smoothly updated by temurin jdk (with check if other 3rd party repos are enabled)

java-latest-openjdk remain also maintained in Koji, as it is necessary testing ground for future system JDK.

It was never an intention to repack a binary Temurin blob in Koji (just in case anybody will think about it). It is not an intention to get rid of maintaining System JDK. However once JDK will no longer be System jdk in any live Fedora, it will be orphaned/closed in favor of Temurin JDK. So once f42 will go out we will continue to maintain only jdk 23+21. In some short time, we will maintain 25+21, a bit alter 26+25+21ā€¦ And once 25 will become system JDK in all live fedoras, we will ditch 21 in favor of Temurins

:link: java packages requires mass change

The javastack (via javapackages-tools) will be reworked to:

  • encapsulate dependencies on system jdk (or any other koji-based jdk) to javapackages tools
  • allow any application to work on any, even 3rd party java

This should be achieved via following chnages to reqires changes and generated changes:

  • javapackages-local for packages with ant or no build - requires java-%{system}-openjdk-devel (%jpackage_script)

    • javapavckages-local%VERSIONED for older ones
    • For slower transitions to newer jdks

  • javapackages-tools

    • requires java-%{system}-openjdk-headless
    • javapackages-tools%VERSIONED for older ones
    • Do not requires java-%{system}-openjdk
      • Will not be added - satisfied by Javapackages-tools with java || java-xyz-openjdk requires

  • Requires generator which crawls through launchers of packages (including jpackage_script ) which source java_functions

    • will be pointing to used jre headless
    • %jpackage_script is implicitly affected by generator and will generate requires to corresponding %{build_time_sdk's}-headless jre (which is currently system jdk, which is jdl 21, unless specified differently)

  • Other packages will need to manually adjust from java-%{system}-openjdk-/headless/devel to java-(system+1)-openjdk-/headless/devel

    • This affects mass rebuilds (instead of just release++ a java-xy-openjdk must do xy++). Positive si that there is more time to do that
    • Indirectly this is not enforcing new system jdk when new LTS is promoted in Fedora
      • Otherwise generic java-devel will no longer satisfy new systemjdk after system bump

  • JAVA_HOME remains main override (rpm generated requires are not affected (maybe todo?))

Java Packaging Guidelines :: Fedora Docs will be adjusted accordingly

the packages built by pure javac or jsut build requires java without any javapackages tools will be adjsuted manually

Note, that this is much smaller effort then it looks like. 99% of packages are living with generated provides, and will get the change automagically. The remaining - aprox 10 - packages will be handled manually

:link: Feedback

todo

:link: Benefit to Fedora

The number of legacy JDKs have grown, and hand in hand with that the number of theirs usages dropped to minimum. It seems there is no longer any need to maintain them, as theirs usage is only highly specialized. By providing 3rd party repo, we allow the specialized use-cases to continue to exist. By discontinuing theirs build in koji we well untie or hands to move forward and focus on future JDKs. Also we will enable fedora to provide highly stable, often updated, secure, 100% integrate-able and passionately maintained builds of legacy JDKs, which will serve as proper replacement if really needed. As a side effect of the changes in provides/requires, we will allow every JDK, from any vendor, which follows unofficial packaging JEP (which covers java and javac alternatives master and java/java-devel provides) to be effectively part of system if wanted, and not just silent companion.

:link: Scope

  • Proposal owners:

  • Other developers:

    • javapackages-tools, maven and ant maintainers are already on board to to totally decuple system jdk from installed java

  • Release engineering: #Releng issue number

    • I think the mass rebuild will not be needed

  • Policies and guidelines: N/A (not needed for this Change)

    • java packaging guidelines will be updated

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

    • This proposal is aligned with Fedora mission - to be on top of technology. We want to focus on newer JDKs, and still provide comfortable access to legacy ones,

:link: Upgrade/compatibility impact

No meter what approach will be selected at the end, there will be upgrade impact.

  • in ideal usecase, the JDKs from koji simply replaces themselves by those from Eclipse Temurin
  • in worst case, user will just get disabled 3rd party repo and updated docs.

In all cases system jdk will remain on machine, and in all cases legacy jdks will be replaced or disappear. I would really be unhappy to simply discontinue them, and leave unmaintained software on target boxes.

:link: Early Testing (Optional)

Do you require ā€˜QA Blueprintā€™ support? Y

:link: How To Test

No JDK on system

  1. get system without java
  2. update to next fedora
  3. no JDK should be there

Only system JDK on system and future STS jdk

  1. get system with system jdk only
  2. update to next fedora
  3. JDK should be there

Only legacy JDK

  1. get system withotu any JDK
  2. manually install any of legacy LTS jdks
  3. update to next fedora
  4. the legacy jdk should not be there or should be gone

System JDK and legacy JDK

  1. get system with system jdk only
  2. manually install any of legacy LTS jdks
  3. update to next fedora
  4. system JDK should be there
  5. the legacy jdk should not be there or should be gone

:link: User Experience

As already described, basic users should not notice change. Advanced users should not lost.

:link: Dependencies

Several (less then 10) packages will lost theirs main dependencies. Those list will be enumerated. Those packages will need to orphan and move to different kind of distribution or update. Main java stack - the packages depending on system java/java-devel/java-headless/java-packages-tools and similar, should not notice change.

:link: Contingency Plan

  • Contingency mechanism: If we fails to introduce Eclipse Temurin JDKs repo, we will simply orphan legacy JDKs as written earlier
  • Contingency deadline: 1. December 2024
  • Blocks release? Yes

:link: Documentation

Only eclipse temurin install pages and java packages guidelines

  • todo link1
  • todo link2

:link: Release Notes

tbd

Last edited by @amoloney 2024-09-24T09:42:49Z

Last edited by @amoloney 2024-09-24T09:42:49Z

2 Likes
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

Just for clarification - by ā€œclosingā€ do you mean to ā€œretireā€ these older OpenJDK packages? ā€œclosingā€ has no defined meaning in this context.

4

Hi!. Right. I had elaborated on this in detailed description: Changes/ThirdPartyLegacyJdks - Fedora Project Wiki

There are several options of getting rid of them.

5

But generaally by close, I ment that they will not be possible to reopen. That java-maint will remian owners, but the apckages will not contain java - it will be jsut metapackages or simply nothing.

Note that similar thing happened for jdk6 and 7, where the packages were reintroduced as java-6/7-openjdk-legacy

6

Also note that java-6/7-openjdk-legacy was quie a disaster - ā€œnormal packagerā€ even if it is senior c/ajva developer, is moreove unable to maintain legacy JDK.

7

Although there are going to be remarkable benefits from this change, I would like to express my concerns for this proposal.

  1. From my perspective, the proposal seems to conflict with Fedoraā€™s core principles. Relying on third-party repositories to satisfy dependencies for core packages is a departure from Fedoraā€™s usual approach. Shifting packages to third-party repositories may dilute Fedoraā€™s identity as a self-contained, community-driven distribution that ensures all components meet its standards.
  2. Although current contributors participate in both Fedora and Temurin, there is no guarantee that Temurinā€™s long-term goals will continue to align with Fedoraā€™s guidelines, which could result in future conflicts.
  3. Adoptium Temurin may not adhere to Fedoraā€™s security and review processes, potentially introducing risks.
  4. With JDKs maintained externally, Fedora users may face delays or complications in receiving support and bug fixes, as issues would need to be escalated to an external project.
3 Likes
8

What are those packages?

The packagers of those programs should probably be listed under ā€œother developersā€. Not by name, I mean ā€” but as I understand the change, they will need to do something.

What is the recommended ā€œsomethingā€? Bundling dependencies?

I donā€™t love thisā€¦ :-/

9

Iā€™m not sure if you were including this in support or not, but if not it gets worse than that.
Up until now, theyā€™ve pretty much always had several months delay until supporting new Fedora versions (after stable release, which interestingly AdoptOpenJDK never had to the same extent).
I donā€™t believe thatā€™s acceptable for something intended to be a replacement for official Fedora packages.

Also worth noting: End users that play Minecraft definitely will notice. That might even be one of the largest (if not the largest) use cases of Java in Fedora outside Fedoraā€™s own packages? You canā€™t just run older versions, especially if modded, on newer Java versions than they were designed for. (Neither can you tell players to play newer versions.)

10

One of them is flexmark-java, which I maintain. For reasons I do not yet understand, flexmark-java does not work correctly with OpenJDK 21. Upstream has not yet chimed in on the matter. If any Java developers in the audience have a few minutes, I would appreciate any clues you can offer on what is going wrong.

11 
From my perspective, the proposal seems to conflict with Fedoraā€™s core principles. Relying on third-party repositories to satisfy dependencies for core packages is a departure from Fedoraā€™s usual approach. Shifting packages to third-party repositories may dilute Fedoraā€™s identity as a self-contained, community-driven distribution that ensures all components meet its standards.

This is wrong assumption. There will be nothing left what rely on older LTS javas. However there is really nearly nothing left. Form packages which relay on it, upstream usually moved to flatpak or somethingbundling theirs own java. The temurin jdks will not be supplemnting the javastack runtime for fedora. They will be available for developers, for 3rd party applications and so on.

Although current contributors participate in both Fedora and Temurin, there is no guarantee that Temurinā€™s long-term goals will continue to align with Fedoraā€™s guidelines, which could result in future conflicts.

Thet may be true. But then The temurin repo may be removed, or temurins can be contributed to. TBH, it will be a but more stable platform then current packages (I really neglect all older jdks then 21, and because of necessary care for those old ones I neglect also 21+. Time have become enemy from some point:( ) By dropping older LTSs I will be able to take more care about temurins and baout system jdsk (and future jdks) in fedora.

Adoptium Temurin may not adhere to Fedoraā€™s security and review processes, potentially introducing risks.

That may be true, but TBH, review is much more strict for temurins, then for Fedora, where package contributor is solemn overlord (and can even introduce backdoor without anybody noticing - at least for a while).

With JDKs maintained externally, Fedora users may face delays or complications in receiving support and bug fixes, as issues would need to be escalated to an external project.

That is not true. Adoptium is (unluckily) much faster then Iā€™m. Especially with important java CVE fixes. Of course there may be exceptions.

Thanx a lot for reply. Highly appreciated.

1 Like
12

What are those packages?

Hmm. It seems that since last time my query went wild, or many packages were orphaned. But After a quick check I found only java-openjfx8 and flexmark-java . Even the rstudio is goneā€¦

I donā€™t love thisā€¦ :-/

Sorry for that. The closest Iā€™m getting to that is Changes/ThirdPartyLegacyJdks - Fedora Project Wiki because the change in provides will need to be docmuneted the most. And that is still settling down. Ideally it will be absolutely transaprent to users. In worst case I will do some 10-20 seds. Iā€™m still on that.

I will mention it here

1 Like
13

Iā€™m not sure if you were including this in support or not, but if not it gets worse than that.
Up until now, theyā€™ve pretty much always had several months delay until supporting new Fedora versions (after stable release, which interestingly AdoptOpenJDK never had to the same extent).

How come? they are faster with Quarterly Oracle CPU release, they are faster with newest STS release. They always had all JDKs.

I donā€™t believe thatā€™s acceptable for something intended to be a replacement for official Fedora packages.

Iā€™m not sure I understend the ā€œgets worseā€. Can you elaborate a bit more? Still the Temurins are option. In all cases old LTS jdks will be gone anyway.

Also worth noting: End users that play Minecraft definitely will notice. That might even be one of the largest (if not the largest) use cases of Java in Fedora outside Fedoraā€™s own packages? You canā€™t just run older versions, especially if modded, on newer Java versions than they were designed for. (Neither can you tell players to play newer versions.)

Iā€™m not aware of this usecase. Can you elaborate a bit more please? If I recall, Minecraft requires simply java, any java. Does nto meter if it is fedora rpms or 3rd party tarball. Then it detects the java it needs. But ,y information are very old. Please tell me a bit more, I do nto want to harm this usecase without justification

14

One of them is flexmark-java, which I maintain. For reasons I do not yet understand, flexmark-java does not work correctly with OpenJDK 21. Upstream has not yet chimed in on the matter. If any Java developers in the audience have a few minutes, I would appreciate any clues you can offer on what is going wrong.

Hm. So it builds, and works fine, only some tests fails (and I expect some behaviour in runtime is affected). Correct?

15

It looks like @mizdebsk has suggested upstream a potential fix. Are you able to test that locally as a patch to the flexmark-java RPM, against java-21-openjdk?

1 Like
16

Taht is not upstream. That is MIkolai , maven/ant/java-packages Fedora maintainer. BUt it seesmt o be fixing the issue, so worty as srpm-patch for sure.

17

Edited, thanks.

18

Iā€™m not aware of any delays in releasing new JDKs either, but thatā€™s not the issue I mean. The issue I mean is the Adoptium repository updating to support newly released Fedora versions. Interestingly, according to their Artifactory, for Fedora 40 it was just a day after release, but for Fedora 39 it was like 2.5 months. Fedora 39 released 07.11.2023, Adoptium added support 24.01.2024. For Fedora 38, it was even 4 months, on 02.08.2023.
Maybe that improved now after all, but Iā€™d prefer day one support or even during beta. After all, the RPMs they distribute for each release are identical, so surely itā€™s not that much effort.

Funnily enough while looking for that I also saw this:
image

Not quite. It doesnā€™t care about where the Java build is from, yes (as long as whatever launcher you are using lets you use it), but the major version (and what runtime it actually is, i.e. realistically just OpenJDK/HotSpot vs OpenJ9, with GraalVM counting under HotSpot) does matter.
Mojangā€™s own launcher does not require Java at all anymore, and downloads their own runtimes, which is an old Oracle JDK 8 and some Microsoft OpenJDK builds. Some launchers are also able to use Mojangā€™s Java distribution, others require the user to deal with installing Java.
Then, we also have dedicated servers, where youā€™re pretty much just handed a JAR file and get to figure out how to run it. Of course, Linux is not an uncommon choice for this even among Windows desktop users : )
Up until Java 8, this used to be a lot more chill. Earlier Minecraft versions were originally built against and used Java 6, later this was upgraded to Java 7 and now 8. Since around Java 11, their LWJGL 2 build no longer works (which is related to symbol versions and some really weird behavior of glibcā€™s loader around them). LWJGL is the Library they use to call into OpenGL, so this part only affects clients.
As for modded, LaunchWrapper, which both old vanilla Minecraft (for compatibility reasons, they were originally Java Applets after all) and Forge up to 1.12 use, relies on some assumptions related to ClassLoaders that simply no longer hold true as of Java 9. Some mods actually tried parsing standard library bytecode using ASM (this means modloaders needed updates to support even Java 8, as ASM is not forward compatible). Some mods also rely on standard library reflection thatā€™s nowadays illegal.
Nowadays, pretty much everyone parses standard library bytecode, because ASM does this if you ask it to compute stackframes, and a library thatā€™s used everywhere (Mixin) does. So, we only have as much forward compatibility here as ASM had at a given point in time. Which is not a lot.
Now, you might want to say ā€œjust play the latest versionā€, which is mostly reasonable if you just play vanilla anyways (except maybe for the hardcore 1.8 players), but itā€™s not as easy for mods, which are highly version dependent and tend not to implement world upgrade mechanisms unlike vanilla. Modpacks are also built targeting a single version.
Vanilla currently has versions officially targeting Java 8, 16 (but most people use 17 for that one), 17 and 21.

Oh and a last point, these days for developing mods I actually tend to use Zulu, GraalVM or JBR builds installed from tar files, mostly because of 2276245 ā€“ full_sources should not be in the same java-*-openjdk-src package as src.zip, because I want to have standard library sources in my IDE but donā€™t need nor want an unzipped copy of the whole JDK sources.

19

I believe this represents a relatively niche use case. Though some users, particularly within the Minecraft community, may require specific Java versions, these scenarios donā€™t affect the majority of Fedora users. For those with highly specific requirementsā€”such as modding older Minecraft versionsā€”manually downloading the appropriate Java runtime from a third-party source should remain a viable solution.
Custom configurations and not relying solely on what an OS platform has to offer is common practice in specialized gaming environments.

20

At the bottom they have indeed only one repo for all RPM based systems. And that si populated by repacking centos7 based tarballs to rpms, so it shouldnto be facing any technical issues.

Thanx for bringing it up. I will ise it up on next Adoptium meeting and will keep an eye.

Thanx a lot for writing it up! I was moreover not aware of anything from it (except LWJGL, whcih I was working with pretty long). Educative reading indeed:)

However generally I do not see anythig in it to be going gainst thit particular proposal. As Dimitris wrote, it is really a corenr case.

Btw - wyou woudl anybody need Zulu??? I had actually considered it dead for ages, axcept few poor souls which bounded themselves to it in last centuryā€¦

As for 2276245 - I agree it should have to go to its own package:( One of the leftovers I forget to finish. Sorry.