| 24 Sep 2025 |
 msgilligan | I'm tempted to write a minimalist JDK-based build tool that works very well with Nix. (I will almost certainly resist this temptation) | 15:17:26 |
| msgilligan | (Especially given that I haven't even found the time to experiment with this one: https://github.com/sormuras/bach) | 15:19:02 |
| msgilligan | The idea of simply "orchestrating" built-in JDK tools seems very Nix friendly. | 15:19:54 |
 emily | can you make AWT/Swing/whatever a separate module? thinking about the JDK headless vs. non-headless build distinction here. | 15:20:00 |
| emily | I'm guessing "no because legacy" | 15:20:08 |
| msgilligan | I don't know what the exact difference between a headless and non-headless JDK is. (Working with Nixpkgs is forcing me giving me the opportunity to learn more about how JDKs are assembled.) I know that Jigsaw (the module JDK structure introduced in Java 9) did make the awt and swing components into modules, but I'm not sure if there are additional differences in the JDK packages. | 15:22:35 |
| msgilligan |
I'm guessing "no because legacy"
Could be
| 15:22:46 |
| emily | I don't know if it's a JDK term or just our term. but it gates the X11, GTK etc. dependencies | 15:31:54 |
| emily | like we just set the flag to build that stuff or not and give the dependencies or not based on that. | 15:32:12 |
| emily | because ideally a web server doesn't pull in GTK | 15:32:19 |
| emily | in an ideal world AWT/Swing are just a separate package you can pull in like JFX | 15:32:35 |
| msgilligan | Yeah, and probably the JDK modules for AWT, etc. rely on the dynamic libs being there but don't bundle them. But I don't know how that works. | 15:33:04 |
| msgilligan | * Yeah, and probably the JDK modules for AWT, etc. rely on the dynamic libs being there but don't bundle them (or provide e mechanism to install or link them.) But I don't know how that works. | 15:34:28 |
| msgilligan | * Yeah, and probably the JDK modules for AWT, etc. rely on the dynamic libs being there but don't bundle them (or provide a mechanism to install or link them.) I don't know how that part works. | 15:34:50 |
| emily | it looks like it might just be a matter of setting java.library.path or something. or patching to use System.load | 15:53:40 |
| emily | anyway, less important than JFX for sure. | 15:54:04 |
| emily | I guess it is maybe more difficult, because there is specific JNI C code. I don't really know how you do JNI linking to native libs in general | 15:55:33 |
| emily | oh, but it will do dlopen: https://github.com/openjdk/jdk25u/blob/master/src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c#L98 | 15:56:53 |
| emily | so actually you can totally provide it GTK at runtime only. cool. | 15:57:00 |
| msgilligan | Looks like Temurin 25 is almost ready. I'm updating the draft PR now. aarch64-linux seems to be the only thing missing. | 15:57:04 |
| msgilligan | I assume we can't merge it until aarch64-linux is there? | 15:57:42 |
| emily | I think we could do that without splitting it out of the JDK package – just always build the stuff, but don't link it directly against GTK, and it'll only work if you have it on the library path at runtime. | 15:57:47 |
| emily | as in, they haven't put up the binaries yet? I'd wait, yeah. | 15:58:05 |
| msgilligan | Yeah. I think all the others we care about are there. (x64 linux, and both x64 and aarch64 darwin are there) | 15:58:58 |
| msgilligan | I'll update the PR anyway, so the ones that are there can run through CI | 15:59:54 |
| emily | the CI "resets" every time you push anyway | 16:03:01 |
| emily | so no rush there | 16:03:06 |
| emily | well, I guess it avoids the actual build since it'll have it cached, but the real slow part is waiting for the queue… | 16:03:20 |
| msgilligan | nix build .#temurin-bin-25 .#temurin-jre-bin-25 seems to have produced runnable java and javac | 16:03:27 |
| msgilligan | I already pushed the update | 16:03:46 |
