| 6 May 2026 |
 dish [Fox/It/She] | the AQAVit test suite seems to be very weird to run offline though | 19:26:35 |
| dish [Fox/It/She] | * the AQAVit test suite seems to be very difficult to run offline though | 19:26:50 |
| dish [Fox/It/She] | * the AQAVit test suite seems to be very difficult to run offline though
(and frankly it's not 100% guaranteed that AQAVit would help us, but could help discover any potential Nix-specific bugs in full source JDK build chains) | 19:29:22 |
| dish [Fox/It/She] | * also a second thing I'm looking at for after bootstrapping work is done(so very long-term) is to integrate AQAVit testing into the nixpkgs JDK build process(minus performance testing because build hardware can be very different of course)
to elaborate slightly more, I'd only run this on end-user JDKs that we actually give to users as usable, not any intermediate ones such as jdk9/10 | 19:39:31 |
 msgilligan | I took a look at that, too. It seemed like a big project, though. | 20:27:52 |
| msgilligan | What I think would help with JDK maintenance is to have some modular filesystem schemas and basic utility tests that can run from Nix CI. i.e. a library that can be used test multiple JDKs. It seems like there is currently some duplication of effort for this on the individual JDK packages. | 20:30:07 |
| 8 May 2026 |
|  whispers [& it/fae] joined the room. | 19:02:58 |
|  Benedikt joined the room. | 19:03:32 |
|  Bart joined the room. | 19:35:39 |
| dish [Fox/It/She] | In reply to @msgilligan:matrix.org
What I think would help with JDK maintenance is to have some modular filesystem schemas and basic utility tests that can run from Nix CI. i.e. a library that can be used test multiple JDKs. It seems like there is currently some duplication of effort for this on the individual JDK packages. so, looking towards this, I think the best thing we can do at the moment for increased test coverage is to work towards building JTReg, since the openjdk source code includes tests we can run with JTReg which do not require additional test downloads(unlike AQAVit) | 22:22:04 |
| dish [Fox/It/She] | I do also agree there's potential to reduce the amount of duplication in packages, which I'll look into first. | 22:22:32 |
| 9 May 2026 |
|  André Lima joined the room. | 11:42:28 |
 Benedikt Ritter (britter) | https://github.com/NixOS/nixpkgs/pull/484741 rebuild-linux:1001-2500 🫠 | 14:03:23 |
| Benedikt Ritter (britter) | @infinidoge:inx.moe you said it's possible to use ofborg to run these massive rebuilds, because we can't expect everybody to have machine to run nixpkgs-review on such massive changes.
How does that work? Just @ofborg test <package-name>? That's not the same running nixpkgs-review though. | 14:11:10 |
| Benedikt Ritter (britter) | From https://github.com/NixOS/ofborg:
Be gentle; try not to run mass rebuilds or massive builds (like Chromium) on it.
😅
| 14:15:19 |
| dish [Fox/It/She] | here's a question. do we need the src.zip that is included in the JDK outputs? That just contains the source code, and it's not needed at runtime afaik. In openjdk 25, it's 53MB, which we could get rid of to shrink closure sizes slightly. | 17:33:10 |
| Benedikt Ritter (britter) | Sounds good to me. I doubt that it's needed. But I don't know 🤷♂️ | 17:44:19 |
| dish [Fox/It/She] | I'm not sure as well, which is why i asked here 😅 | 17:47:02 |
 Infinidoge 🏳️⚧️ | It might be required for inspecting the definitions of Java objects | 18:15:21 |
| Infinidoge 🏳️⚧️ | Would have to test though | 18:15:38 |
 emily | IDE support? | 18:17:08 |
| Infinidoge 🏳️⚧️ | I believe so, not entirely sure how to interpret that as a question | 18:18:06 |
| emily | as in, perhaps src.zip is used for looking up things in the stdlib from IDEs | 18:19:13 |
| emily | (that's what the Rust source code gets used for at least) | 18:19:21 |
| msgilligan | According to Claude:
The location within the JDK image is a committed upstream interface. OpenJDK explicitly defines src.zip (alongside things like jrt-fs.jar) as a file at a path intended for external use, contrasted with the contents of lib/ which are private implementation. So when you build OpenJDK, the build system produces src.zip as part of the standard image layout.
| 18:23:27 |
| msgilligan | and:
It exists so that IDEs and debuggers can show you the actual source of, say, ArrayList.add() when you step into it or hit "Go to definition," instead of just decompiled bytecode or stub signatures. IDEs like Eclipse and IntelliJ pick it up from $JAVA_HOME and attach it as the source for the runtime classes, which is what makes "view source" work for JDK classes out of the box.
| 18:24:00 |
| msgilligan | and:
There's nothing Nix-specific going on — removing it would actually be the unusual choice, and it would break IDE source navigation for anyone pointing their IDE at the Nix-built JDK. Some Linux distros do split it out into a separate -source package (as the Bazel issue above shows for Ubuntu), but Nixpkgs keeps the upstream layout intact.
| 18:24:21 |
| msgilligan |
If you're trying to slim down a closure and don't need IDE source attachment, you can drop it in a postInstall hook on an override, but for a general-purpose JDK package keeping it is the right default.
| 18:24:42 |
| Infinidoge 🏳️⚧️ | Suffice it to say no need to drop it l | 18:24:58 |
| Infinidoge 🏳️⚧️ | * Suffice it to say no need to drop it | 18:25:08 |
