-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JDK updates and removals #344544
Merged
Merged
JDK updates and removals #344544
Changes from all commits
Commits
Show all changes
22 commits
Select commit
Hold shift + click to select a range
ff4d69b
temurin-{,jre-}bin: temurin-{,jre-}bin-22 -> temurin{,jre-}bin-21
emilazy 6da99f2
temurin-{,jre-}bin-{8,11,17,21,22}: update
emilazy 3da3ed0
temurin-{,jre-}bin-23: init at 23.0.0
emilazy 44cdf2f
zulu8: 8.0.{392,402} -> 8.0.422
emilazy 72f2e94
zulu11: 11.0.22 -> 11.0.24
emilazy 3afd5ff
zulu17: 17.0.10 -> 17.0.12
emilazy c12e8ac
zulu21: 21.0.2 -> 21.0.4
emilazy 309cfa5
zulu23: init at 23.0.0
emilazy adf0459
openjdk: remove unused bootstrap files
emilazy 45bb402
openjdk21: remove from `info.json`
emilazy bc12b04
openjdk8: 8u412-ga -> 8u422-ga
emilazy 0a94520
openjdk11: 11.0.23+9 -> 11.0.24+8
emilazy 64e24d1
openjdk17: 17.0.11+9 -> 17.0.12+7
emilazy fac90a7
openjdk21: 21.0.3+9 -> 21.0.4+7
emilazy 00a8a1c
{openjdk,openjfx}23: init at 23-ga
emilazy 81c3d76
jextract: pin JDK 23, mark as broken
emilazy 092c108
cryptomator: pin JDK 23, mark as broken
emilazy 56d6fe1
moneydance: pin OpenJDK 23
emilazy b32d2c0
jabref: pin JDK 21 and OpenJFX 23
emilazy 35cc147
zulu22: drop
emilazy 732642b
{openjdk,openjfx}22: drop
emilazy d19c7e8
temurin-{,jre-}bin-22: drop
emilazy File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,12 +1,7 @@ | ||
| { | ||
| "22": { | ||
| "version": "22.0.2-ga", | ||
| "repo": "jdk22u", | ||
| "hash": "sha256-Zo1LOumkt9zTaPqbDcRL8lVJMqVle0QqzThtIz0JRNo=" | ||
| }, | ||
| "21": { | ||
| "version": "21.0.3-ga", | ||
| "repo": "jdk21u", | ||
| "hash": "sha256-zRN16lrc5gtDlTVIQJRRx103w/VbRkatCLeEc9AXWPE=" | ||
| "23": { | ||
| "version": "23-ga", | ||
| "repo": "jdk23u", | ||
| "hash": "sha256-lcLnWAiskWindOqWmOWiIHiYKXGSJZK4d20k19QZfrE=" | ||
| } | ||
| } |
This file was deleted.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
File renamed without changes.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be more respectful to jextract users to wait with the jdk22 removal
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think keeping older versions of Java that are possible insecure is more of an issue than having one specific package to break. We could just have marked the JDK22 (and all packages that depend on it) as insecure instead and keep it for longer, but I concur that we should, if anything, to reduce the number of Java packages in the tree to make sure that the ones that we have are up to date.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
jextractfor the LTS JDK 21 is still in‐tree. There’s been seemingly no movement in thejextractrepository porting it to a non‐EOL JDK, so I don’t know what’s going on there. The same upstream that maintainsjextractsets the OpenJDK support policy and since it is guaranteed that we will get these versions going EOL every release (when it’s not time for a new LTS) we can’t let the list of insecure, unsupported JDKs keep growing indefinitely, as happened before the 24.11 cycle. I would prefer we move to a scheme like Fedora where the latest JDK is available asopenjdk_latestand simply rolls over to the new version when released.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well all software is possibly insecure. I know that you mean unmaintained, which is similar.
That would seem like a better solution to me.
I agree with this as well. But I would suggest something like what I see for java in Debian Trixie where they support:
At an absolute minimum provide: LTS versions, the latest release, the previous release. It would also be nice to see EA versions installable through Nix, but obviously someone has to do the work.
Releases that are unmaintained upstream could be marked as unsupported/insecure/deprecated, just so long as projects aren't broken without a few months warning.
In the case of
jextract, which is a tool to build bindings for Java's Foreign Function & Memory API which went final in JDK 22. The only way (I'm pretty sure) to build bindings for the final API is with the JDK 22-based jextract. So, at this point, there is no way to do that using nixpkgs.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I mentioned in my reply above, this version is not very useful because it is for a non-final FFM API and requires use of JDK 21 with "preview features" enabled.
This appears to be the case and is disappointing. Maybe someone should reach out to the OpenJDK project and ask about it.
I agree. But hopefully there's a way to do this with a little more warning (e.g. a 3-6 months) to dependent projects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, looking at the latest advisory for Java it seems there are new security issues affecting all supported Java versions. It is very unlikely this doesn't also affect JDK 22 so we actually know it has security issues: https://openjdk.org/groups/vulnerability/advisories/2024-10-15.
Those security advisories are released every 3 months and almost always have at least one security issue, so for a version that is maintained by 9 months like our stable branches we are unlikely to ship the previous version and keep it secure.
I actually like the proposal from @emilazy here to keep all LTS versions+
openjdk_latestwith the last version, because at least we can ensure that it is possible to keep our JDK versions up to date in stable.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW I spent about 30 minutes looking into a way to patch
jextractfor the latest JDK and I didn’t succeed, but I suspect someone with more familiarity would have an easier time with it. It didn’t seem like it should be impossible by any means; it just exceeded the time‐box I had allocated to it. If we could do that then it could also be sent upstream to OpenJDK.The OpenJDK release and support cycle is fixed – the 6 months warning is when a new non‐LTS release comes out, and the 3 months warning is 3 months after that. That cycle is on the OpenJDK project; we don’t have the resources to support them longer than upstream does. We’ve regularly lagged behind on security‐critical updates even to the versions we currently have, and 24.05 was in a much worse state (I think all the JDKs there should actually be marked as
knownVulnerabilities).I believe our stable branches are actually maintained for 7 months? But: that means that OpenJDK 23 is going to go EOL during the 24.11 cycle, which is really awkward. Either we mark it with
knownVulnerabilitiesand have only programs using LTS JDKs working without a security version for the last few months of the release cycle, or we backport a bump to the next JDK and potentially break other software in the process. I believe long‐term support distributions like RHEL don’t even bother shipping non‐LTS JDKs. It’s really something you should only depend on if you can be sufficiently agile at supporting upcoming versions, given the upstream policy.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This mailing list message claims that
jextractshould basically “just work” with JDK 23. That was unfortunately not my experience, but it could just be build system issues I’d be running into, so if someone wanted to have a go at getting the package unbroken I suspect it shouldn’t be too difficult.Edit: It looks like they just released an early access build a few days ago that they claim has Java 23 compatibility. Perhaps a version bump is all it would take now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The arguments about security are compelling. And I know this is a volunteer project with limited resources. I am new to Nixpkgs and am trying to contribute as much as I can (e.g. #271127), but am not (yet) ready to try to (help) support OpenJDK itself.
I have been trying to replace (as much as possible) Homebrew and SDKMAN! with Nixpkgs.
I personally prefer to focus on getting
jextractupdated: #354591But I also want to share my experiences a a Nixpkgs user and having something like
jdk22disappear so quickly is not very friendly to downstream projects. A difference between installing JDK binaries with Homebrew or SDKMAN! and using Nix flakes is that dropping JDK 22 will actually break Nix builds, whereas Homebrew or SDKMAN! will allow you to leave your old (unmaintained/insecure) JDK installed and usable.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, it’s possible to pin the last Nixpkgs version with OpenJDK 22, and use that package alongside other packages on your system, thanks to Nix’s hermetic pinning of dependency trees. That’s of course inconvenient, and in some ways slightly worse than if we were carrying an insecure‐marked OpenJDK 22 in the current tree (namely: its dependencies won’t get updates either, though since the JDK itself is probably the biggest source of vulnerabilities in its dependency closure that might not matter too much), but hopefully it can at least serve at a pinch when you really can’t do without the old version. (It also avoids having to build the JDK yourself, since we don’t spend Hydra build farm resources on insecure packages.)
I realize it’s frustrating from a user point of view, though, and I sympathize with the pain of dealing with short support cycles – ideally OpenJDK would provide an overlapping support window for their non‐LTS releases, but they don’t. I think they would have the ability to do that; we support a one month security support overlap between our own stable versions despite having considerably fewer resources than Oracle. I don’t really know why they don’t; I was wondering if perhaps it’s because they sell extended commercial support, but that’s only for the LTS releases. I get the impression that they consider their non‐LTS releases to essentially be previews for the next LTS.
If you want to try updating
jextractto the latest early access build and seeing if it’ll work on JDK 23 that would be great, and please do ping me for review! I can try to help if you run into any issues as well. I didn’t want to mark it as broken here but making sure we had the latest supported JDK and weren’t at risk of shipping an EOL one in 24.11 took priority. If we could get it fixed before the 24.11 release I’d be very happy.