 | NixOS JVM | 110 Members |
| 23 Servers |
| NixOS JVM | 110 Members |
| 23 Servers |
| Sender | Message | Time |
|---|---|---|
| 27 Mar 2025 | ||
 emily | tbh I don't really think of it as deleting. just as an update. there's the LTS releases and a rolling stream of the latest one | 03:32:21 |
| emily | knowmVulnerabilities would be adequate but it does mean that you will have to compile it yourself | 03:32:58 |
| emily | and that takes a rather long time | 03:32:59 |
| emily | BTW we do keep binary JDKs around and marked EOL | 03:33:10 |
| emily | because those don't impose any meaningful maintenance burden and also have no compile cycle | 03:33:33 |
| emily | so Temurin is an option | 03:33:48 |
 msgilligan | I'm getting the feeling that "we don't like to gamble with users' security" is at least partly a rationalization for avoiding maintenance burden on the source (and if that's the case, it makes sense and have no problem with it) Because the Temurin 23 will have the same vulnerabilities as the OpenJDK 23 built from source. I'm not trying to be argumentative, I just want to understand what you feel the tradeoffs are. Because I totally get the maintenance overhead argument and completely respect it. For my use case, using binary JDKs is probably fine. (Though I would migrate to the one built from source when JDK 25 is released.) But that also means the interim releases as-built-by-Nixpkgs are getting less testing. | 03:41:57 |
| emily | the gambling was re knownVulnerabilities | 03:44:45 |
| emily | if we set it on both then no gambling | 03:44:56 |
| emily | but one of them takes hours to build and the other seconds | 03:45:05 |
| emily | so the UX is kinda better with the Temurin package once marked | 03:45:19 |
| emily | (and yeah a package that's just a download is very low maintenance) | 03:45:46 |
| msgilligan | But this unmerged PR looks (to my beginner's eye) like it removes Temurin 23 as well: https://github.com/NixOS/nixpkgs/pull/391811/files#diff-79588acae2eadf21386a83519365d48aad6c7162da39897f429bca64ad8437ff | 03:46:02 |
| emily | yeah, it does. I haven't reviewed the PR. I guess I should say "at some point we have done things like this" :) | 03:48:09 |
| emily | FWIW "drop source, mark binary" is how Electron maintainers handle EOLs | 03:48:32 |
| msgilligan | My project will survive no matter what the NixOS JVM team decides, but I really like Nix, want to provide feedback and help as I can, and use Nix as fully as possible in my build. I'm also eventually hoping to get some Java apps into nixpkgs. If the human and infrastructure resources are sufficient for keeping the built-from-source packages in | 03:54:17 |
| msgilligan | I also will try to learn various methods for testing PRs and pre-release branches as much as possible (and how to automate this on some of my systems, if possible) | 04:01:01 |
| msgilligan | If anyone has any pointers to good references on how to do this, it would be appreciated. Especially anything that is Java or Rust focused (I also have some Rust projects I am trying to Nix-ify) I guess I could try to configure GitHub and/or GitLab to pull from release branches, for example. And maybe automatically do | 04:06:22 |
| msgilligan | * If anyone has any pointers to good references on how to do this, it would be appreciated. Especially anything that is Java or Rust focused (I also have some Rust projects I am trying to Nix-ify) I guess I could try to configure GitHub and/or GitLab to pull from release branches, for example. And maybe automatically do | 04:06:57 |
 Tomodachi94 (they/them) | (I'd be willing to vouch for you if you want to be put onto the Java team; I'm probably not the only one who thinks you'd make a great addition) | 04:20:14 |
| Tomodachi94 (they/them) | * (I'd be willing to vouch for you if you want to be put onto the Java team so you get pings for this kind of stuff; I'm probably not the only one who thinks you'd make a great addition) | 04:20:26 |
| Tomodachi94 (they/them) | On the testing PRs bit, our CONTRIBUTING.md is quite good nowadays: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#how-to-review-pull-requests As for testing prerelease branches, we have a system called Hydra which builds packages automatically once they're promoted to a channel. Here's some more information: https://wiki.nixos.org/wiki/Channel_branches | 04:26:46 |
| Tomodachi94 (they/them) | * On the testing PRs bit, our CONTRIBUTING.md has some good advice: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#how-to-review-pull-requests As for testing prerelease branches, we have a system called Hydra which builds packages automatically once they're promoted to a channel. Here's some more information: https://wiki.nixos.org/wiki/Channel_branches | 04:27:01 |
| Tomodachi94 (they/them) | * On the testing PRs bit, our CONTRIBUTING.md has some good advice: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#how-to-review-pull-requests As for testing prerelease branches, we have a system called Hydra which builds packages automatically once they're promoted (id that the right word?) to a channel. Here's some more information: https://wiki.nixos.org/wiki/Channel_branches | 04:27:26 |
| Tomodachi94 (they/them) | * On the testing PRs bit, our CONTRIBUTING.md has some good advice: https://github.com/NixOS/nixpkgs/blob/master/CONTRIBUTING.md#how-to-review-pull-requests As for testing prerelease branches, we have a system called Hydra which builds packages automatically once they're promoted (is that the right word?) to a channel. Here's some more information: https://wiki.nixos.org/wiki/Channel_branches | 04:27:34 |
| emily | In reply to @tomodachi94:matrix.orgI mostly just don't have the time, I'm afraid :) | 12:18:30 |
| emily | I'm happy to try and take a look at stuff I'm pointed out, and do specific bits of work when they dovetail with other stuff I want to do, but if I try to track all the day to day Java stuff I'll just drop the ball on stuff more than I already do | 12:19:03 |
| emily | FWIW I don't think JDK patch updates need more testing than confirming build and maybe a brief perusal of advisories/release notes | 12:20:39 |
| emily | just needs someone keeping track of them (r-ryantm sometimes has issues and isn't always the fastest) and a committer who can allocate the time to merging them | 12:21:33 |
 raboof | Jup. While I think everyone wants to run newer JDKs, many libraries want to support running on JDK8, and the easiest way to achieve that is by building on JDK8 - building with a newer JDK than the target JDK only became reliable when targeting JDK9 onwards... | 14:15:38 |