 | NixOS JVM | 122 Members |
| 27 Servers |
| NixOS JVM | 122 Members |
| 27 Servers |
| Sender | Message | Time |
|---|---|---|
| 24 Sep 2025 | ||
 emily | yes, please :) | 15:02:35 |
| emily | I hate the JFX entangled into the JDK build thing, as you know | 15:02:46 |
| emily | I think that one jlink PR to get rid of that looked pretty good in principle, I forget if I had any complaints about it | 15:03:10 |
| emily | if we can just make everything use it totally separately and kill off the combined build then that's wonderful though | 15:03:23 |
| emily | would simplify everything a fair bit | 15:03:30 |
| emily | we don't have too much in-tree that uses JFX | 15:03:56 |
| emily | double nice would be if we can split out the WebKit part of it rather than having that be a flag đŸ˜† | 15:04:19 |
| emily | (but don't know if their build system makes that viable) | 15:04:25 |
 msgilligan | Oh, yeah the modules approach should help with that, too. | 15:04:57 |
| emily | have you seen the Bazel 8 stuff btw? not sure if you have any care for Bazel | 15:06:22 |
| emily | but our Bazel packaging story is currently a mess and it seems like Bazel 8 might help with that… | 15:06:34 |
| msgilligan | I've been resisting Bazel for years. Maybe that's foolish? | 15:06:52 |
| msgilligan | If it works better with Nix than Maven or Gradle, that might be a selling point... | 15:07:38 |
| emily | worse, I think. | 15:07:45 |
| emily | Nix and Bazel have fairly similar views of the world in many ways, but they're just different enough, and just enough pushing into each other's turf, that the combination causes a bit of a headache. | 15:08:24 |
| msgilligan |
I think this happening in the JFX ecosystem was mostly the result of JFX making a bad design decision that in some cases 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:01 |
| msgilligan | *
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 |
| 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 | 15:22:35 |
| msgilligan |
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 |