JDK updates and removals #344544
JDK updates and removals #344544
Conversation
|
Not going to fix the nixpkgs-vet warning given that it would result in inconsistency with all the other Zulu versions (and the Zulu packaging pattern wouldn’t work with |
ofborg
bot
added
8.has: clean-up
8.has: package (new)
ofborg
bot
requested review from
abbradar,
lucasbergman,
jlesquembre,
bachp and
SharzyL
pkgs/top-level/aliases.nix
Outdated
| @@ -1163,8 +1163,13 @@ mapAliases { | |||
| openjdk20_headless = openjdk20; # Added 2024-08-01 | |||
| jdk20 = openjdk20; # Added 2024-08-01 | |||
| jdk20_headless = openjdk20; # Added 2024-08-01 | |||
| openjdk22 = throw "OpenJDK 22 was removed as it has reached its end of life"; # Added 2024-09-24 | |||
| openjdk22_headless = openjdk20; # Added 2024-09-24 | |||
There was a problem hiding this comment.
| openjdk22_headless = openjdk20; # Added 2024-09-24 | |
| openjdk22_headless = openjdk22; # Added 2024-09-24 |
|
The OpenJDK 22 files still seem to be in the repository, might be an oversight. |
|
@emilazy Thank your for your feedback. I have integrated Corretto because it is used in my organization. Several other people had requested it in the past. Several people have expressed the need for corretto on Darwin which currently doesn't exist. Here is a non-working/draft PR for some context. In my case, the build infrastructure locks down the used Java version (via gradle, One thing I'd like to explore in the future is separate the corretto build from the OpenJDK builds. Currently, |
I concur, unless there is a maintainer committed to maintaining those variations I would also be in favor of just removing them as much as possible. Otherwise they will just bit rot (e.g. stop building) or be a security issue since they get terrible out of date. In my opinion we need to maintain the minimal amount of JDKs possible: so if we need e.g. Zulu JDK8 to bootstrap other JDK for Darwin let's just keep that specific version (this is an example, not sure how Darwin bootstrap works). And ideally keep only OpenJDK as the way to go for Java here in nixpkgs. |
I am committed to maintain Corretto on Linux. I use this daily. I have updated it regularly (here is my latest approved-but-not-merged-PR). |
emilazy
force-pushed
the
push-sskpuxzxzrow
branch
from
8ce2409
to
ee4f58c
Compare
|
I believe that jdk21, jdk17, jdk11 and jdk8 require an update as well. For each of these a new version is available, and they have not been updated in quite a while. |
Yeah, rebase calamity. Fixed.
Fair enough. It’s a bit weird to me that people are pinning requirements for what are, to my understanding, basically builds of the same source code with a handful of patches on top, but clearly there’s some benefit to having it. Since they only ship LTS releases and you’re keeping it cared for, it didn’t cause me any maintenance burden here, and so I have no particular motivation to push for its removal :) Thanks for putting in the maintenance work.
Using Zulu to bootstrap our source OpenJDK 8 on In fact, I would personally lean towards just dropping JDK 8 sooner. Debian already has, for instance.
And this is why shipping five versions of the JDK with the maintainer resources we seem to have is a pain… I’ll see if I can bump them. |
Oh no, I didn't mean to build OpenJDK 8 for aarch64-darwin from Zulu 8, that was an example (e.g.: if we need any JDK8 to bootstrap the remaining OpenJDK versions that we care, we could use Zulu 8 and keep only that in nixpkgs, dropping the other versions). I completely agree that we should not care about having a working OpenJDK 8 build for aarch64-darwin, unless there is official support in upstream.
That I am not completely sure. If there is no packages in nixpkgs that depends on JDK 8 I think it is fine, but there are probably some users of Java 8 out there. I don't think there are a lot of them though, but it is difficult to have any idea of package usage in nixpkgs. |
emilazy
force-pushed
the
push-sskpuxzxzrow
branch
from
ee4f58c
to
f74441c
Compare
emilazy
force-pushed
the
push-sskpuxzxzrow
branch
from
f74441c
to
e61a160
Compare
Pin the latest LTS version for consistency with OpenJDK.
|
(Oops, I forgot to post this.)
I think we bootstrap all versions from an equal Temurin version now, so bootstrap shouldn’t be an issue. The Temurin 8
Yeah, there’s some reverse dependencies. But I have a very particular set of skills. We are, in any case, going to have to deal with the situation once EOL happens. |
|
All the builds went through. This should be ready, modulo version stuff. |
This requires Java 21 but OpenJFX ≥ 22. As OpenJFX 22 is EOL, we use OpenJFX 23, which technically only supports down to JDK 21, but let’s hope for the best.
Actually, nobody even got around to making an alias for this one…
emilazy
force-pushed
the
push-sskpuxzxzrow
branch
from
e903e86
to
d19c7e8
Compare
|
Eval error, can you take a look @emilazy? |
wegank
added
the
12.approvals: 1
|
@ofborg eval |
Seems to be a transient issue. |
| # Not yet updated for JDK 23 | ||
| broken = true; |
There was a problem hiding this comment.
It would be more respectful to jextract users to wait with the jdk22 removal
There was a problem hiding this comment.
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.
The jextract for the LTS JDK 21 is still in‐tree. There’s been seemingly no movement in the jextract repository porting it to a non‐EOL JDK, so I don’t know what’s going on there. The same upstream that maintains jextract sets 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 as openjdk_latest and simply rolls over to the new version when released.
There was a problem hiding this comment.
older versions of Java that are possibly insecure
Well all software is possibly insecure. I know that you mean unmaintained, which is similar.
We could just have marked the JDK22 (and all packages that depend on it) as insecure instead and keep it for longer
That would seem like a better solution to me.
reduce the number of Java packages in the tree to make sure that the ones that we have are up to date
I agree with this as well. But I would suggest something like what I see for java in Debian Trixie where they support:
- 17
- 21
- 22
- 23
- 24-ea
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.
The
jextractfor the LTS JDK 21 is still in‐tree.
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.
There’s been seemingly no movement in the
jextractrepository porting it to a non‐EOL JDK
This appears to be the case and is disappointing. Maybe someone should reach out to the OpenJDK project and ask about it.
we can’t let the list of insecure, unsupported JDKs keep growing indefinitely
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.
Well all software is possibly insecure. I know that you mean unmaintained, which is similar.
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_latest with 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.
FWIW I spent about 30 minutes looking into a way to patch jextract for 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.
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.
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 knownVulnerabilities and 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.
This mailing list message claims that jextract should 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.
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 jextract updated: #354591
But I also want to share my experiences a a Nixpkgs user and having something like jdk22 disappear 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.
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 jextract to 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.
Description of changes
OpenJDK 23 is out, and 22 is end‐of‐life. This packages the new version for OpenJDK source builds, Temurin, and Zulu. I opted to drop the old versions entirely because these non‐LTS releases get released and go EOL every 6 months anyway so I don’t think it makes sense to carry around old derivations marked as insecure for versions with such short shelf lives. Sadly a few things aren’t ready for 23 yet (e.g. because of using the abandoned string template preview proposal), and have been marked as broken.
Some general thoughts on Nixpkgs JDK packaging from an outsider:
OpenJDK source, Temurin, Semeru, Zulu, and Corretto feels like a needlessly high number of JDK distributions to me. Semeru has OpenJ9 and source builds have obvious value. I don’t see a good reason for us to have both Temurin and Zulu. It seems like we use Zulu on Darwin because it supports JavaFX and supports
aarch64-darwinfurther back than Temurin does (because Temurin relies on upstream OpenJDK which hasn’t backportedaarch64-darwinsupport to JDK 8). I think if we could get the OpenJDK/OpenJFX source builds working on Darwin and bootstrap them from Temurin it would be a nicer situation overall; not supporting JDK 8 onaarch64-darwinseems okay. Zulu is pretty neglected, given its tedious manual update process; every Zulu JDK was out of date. If we stop using it on Darwin, I think it could reasonably be removed. (Switching from Temurin to Zulu for bootstrap might also be an option, if the derivation can be made more maintainable.) I’m not sure about the motivation for carrying Corretto; cc @rollf?8, 11, 17, 21, and the latest version is… also a lot of versions to deal with. Backporting FFmpeg changes to old OpenJFXes was fairly painful. At least 8 will go EOL within the next couple years…
There’s way too much copy and paste. The OpenJDK and OpenJFX derivations need deduplicating across versions, Temurin and Semeru are copy‐pasted from each other, the Linux and Darwin derivations of those could probably be deduplicated somewhat… if I end up looking at getting OpenJDK to build on Darwin I might try and do something about the duplication there.
Things done
[ temurin-bin-8 temurin-bin-11 temurin-bin-17 temurin-bin-21 temurin-bin-23 temurin-jre-bin-8 temurin-jre-bin-11 temurin-jre-bin-17 temurin-jre-bin-21 temurin-jre-bin-23 openjdk8 moneydance jabref ] ++ lib.concatMap (jdk: [ jdk (jdk.override { enableJavaFX = true; }) ]) [ zulu8 zulu11 zulu17 zulu21 openjdk11 openjdk17 openjdk21 openjdk23 ][ temurin-bin-8 temurin-bin-11 temurin-bin-17 temurin-bin-21 temurin-bin-23 temurin-jre-bin-8 temurin-jre-bin-11 temurin-jre-bin-17 temurin-jre-bin-21 temurin-jre-bin-23 openjdk8 openjdk11 moneydance jabref ] ++ lib.concatMap (jdk: [ jdk (jdk.override { enableJavaFX = true; }) ]) [ zulu8 zulu11 zulu17 zulu21 openjdk17 openjdk21 openjdk23 ][ temurin-bin-11 temurin-bin-17 temurin-bin-21 temurin-bin-23 temurin-jre-bin-11 temurin-jre-bin-17 temurin-jre-bin-21 temurin-jre-bin-23 openjdk8 ] ++ lib.concatMap (jdk: [ jdk (jdk.override { enableJavaFX = true; }) ]) [ zulu8 zulu11 zulu17 zulu21 openjdk11 openjdk17 openjdk21 openjdk23 ]nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.