NixOS JVM | 121 Members | |
| 26 Servers |
| Sender | Message | Time |
|---|---|---|
| 24 Sep 2025 | ||
*
I think this happening in the JFX ecosystem was mostly the result of JFX making a bad design decision that in a common use case requires using the module path and apps not dealing with it well. Since a bundled JFX worked-around the problem, JDKs with bundled FX became popular. (I don't truly know the reasons why, but this is my theory) Anyway, hopefully the JFX apps we have in Nixpkgs can move past this. | 15:16:32 | |
| 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 | |
| (Especially given that I haven't even found the time to experiment with this one: https://github.com/sormuras/bach) | 15:19:02 | |
| The idea of simply "orchestrating" built-in JDK tools seems very Nix friendly. | 15:19:54 | |
| can you make AWT/Swing/whatever a separate module? thinking about the JDK headless vs. non-headless build distinction here. | 15:20:00 | |
| I'm guessing "no because legacy" | 15:20:08 | |
| I don't know what the exact difference between a headless and non-headless JDK is. (Working with Nixpkgs is | 15:22:35 | |
Could be | 15:22:46 | |
| 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 | |
| like we just set the flag to build that stuff or not and give the dependencies or not based on that. | 15:32:12 | |
| because ideally a web server doesn't pull in GTK | 15:32:19 | |
| in an ideal world AWT/Swing are just a separate package you can pull in like JFX | 15:32:35 | |
| 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 | |
| * 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 | |
| * 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 | |
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 | |
| anyway, less important than JFX for sure. | 15:54:04 | |
| 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 | |
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 | |
| so actually you can totally provide it GTK at runtime only. cool. | 15:57:00 | |
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 | |
I assume we can't merge it until aarch64-linux is there? | 15:57:42 | |
| 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 | |
| as in, they haven't put up the binaries yet? I'd wait, yeah. | 15:58:05 | |
| Yeah. I think all the others we care about are there. (x64 linux, and both x64 and aarch64 darwin are there) | 15:58:58 | |
| I'll update the PR anyway, so the ones that are there can run through CI | 15:59:54 | |
| the CI "resets" every time you push anyway | 16:03:01 | |
| so no rush there | 16:03:06 | |
| 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 | |
nix build .#temurin-bin-25 .#temurin-jre-bin-25 seems to have produced runnable java and javac | 16:03:27 | |