| 27 Mar 2025 |
Tomodachi94 (they/them) | Correct | 00:47:44 |
msgilligan | This is why jextract had to be marked as broken, for example. | 00:48:28 |
msgilligan | And a jextract-21 is practically useless because the features it relies on were "preview" and not final. Then when I updated to the latest jextract it generates code that requires JDK 23, so that forces anything that uses its output to JDK 23. | 00:50:01 |
msgilligan | I would say jextract and jextract-21 should both be removed from 25.05 stable. And as soon as we get jextract 23, I would say we should remove jextract-21 from unstable. | 00:51:32 |
emily | have they not even updated to 23 yet? 🫠 | 00:52:59 |
emily | it's a little bizarre that the OpenJDK project can't keep up with their own release cycle :) | 00:53:16 |
emily | I guess this is why people stick to LTSes | 00:53:27 |
Tomodachi94 (they/them) | Off-topic: Lovely, Nixpkgs has a working Codespaces default now >:) | 00:54:10 |
msgilligan | They have, and I've made a PR that works on aarch64-darwin but not aarch64-linux (thought that may be true of the upstream too) | 00:54:15 |
Tomodachi94 (they/them) | (In theory; it's still setting itself up) | 00:54:30 |
msgilligan | https://github.com/NixOS/nixpkgs/pull/384028 | 00:54:55 |
msgilligan | There have also been some changes upstream and the PR should be updated and rebased (though they don't like they'll help with aarch64-linux) | 00:55:31 |
Tomodachi94 (they/them) | (Everything works out of the box now! No more hacky workarounds needed) | 00:57:46 |
msgilligan | Last week, I actually talked to someone from someone from Oracle who is responsible for jextract (at a JavaOne side event) and he admitted it needed some love.
I'm glad I haven't made it a direct dependency of my build. I just need to install it periodically and use it to generate Java source that I check in to the repository.
| 01:05:51 |
msgilligan | He complained about the LLVM dependencies... | 01:07:03 |
msgilligan | Hopefully things will stabilize around JDK 25 | 01:09:39 |
Infinidoge 🏳️⚧️ | With regards to dropping JDK versions, unless they are actively a maintainability hazard, I would rather we keep as many versions as are reasonable | 01:18:17 |
Infinidoge 🏳️⚧️ | The heuristic I propose is keeping JDK versions between LTS versions, and dropping only when the next LTS cycle begins | 01:18:42 |
Infinidoge 🏳️⚧️ | (I talked with msgilligan about this at PlanetNix for a bit of extra context) | 01:19:46 |
emily | as long as EOL ones are marked knownVulnerabilities there's no inherent problem, but frankly that is going to be a worse UX than using an old Nixpkgs rev in many ways | 01:21:49 |
Infinidoge 🏳️⚧️ | Re: 25.05, I don't know of any notable blockers, meant to come here and ping everyone to ask but you beat me to the punch. Anything like gradle 9 would be nice to have but isn't necessary | 01:22:22 |
Infinidoge 🏳️⚧️ | In reply to @emilazy:matrix.org as long as EOL ones are marked knownVulnerabilities there's no inherent problem, but frankly that is going to be a worse UX than using an old Nixpkgs rev in many ways Isn't it just an allowInsure config? | 01:22:33 |
emily | I am unconvinced that we need to have a greater proliferation of JDKs than e.g. Fedora which does the rolling package for non-LTS, though | 01:22:40 |
emily | In reply to @infinidoge:inx.moe Isn't it just an allowInsure config? and building OpenJDK yourself, yeah | 01:22:52 |
Infinidoge 🏳️⚧️ | I don't think the cache is purged so it probably wouldn't need to be built(?) | 01:23:13 |
emily | dependencies change, so it would | 01:23:59 |
emily | staging cycle invalidates all hashes every few weeks | 01:24:09 |
Infinidoge 🏳️⚧️ | Ah, yeah that would do it | 01:24:09 |
msgilligan | I'm asking for the last two non-LTS on unstable and would be ok with no non-LTS on stable Nixpkgs. | 01:24:17 |
msgilligan | * I'm asking for the last two non-LTS on unstable and would be ok with no non-LTS on stable Nixpkgs. (and the older non-LTS could be marked with knownVulnerabilities) | 01:27:15 |