| 22 Sep 2025 |
|  @ihar.hrachyshka:matrix.org joined the room. | 23:35:23 |
| 23 Sep 2025 |
|  a-kenji changed their display name from a-kenji to kenji. | 10:38:30 |
| 24 Sep 2025 |
 msgilligan | I haven't had a chance to follow-up on this comment, but it looks promising: https://github.com/NixOS/nixpkgs/issues/412283#issuecomment-3325887652 | 04:50:15 |
| msgilligan |
With this workaround, JDK24 compiles correctly with JFX support.
| 04:50:36 |
 emily | looks like shipping the jlink thing would also fix it going by the linked release notes | 05:01:34 |
| msgilligan | I'm thinking we should encourage applications to pull in their JavaFX jars/modules separately from the JDK when possible (which I believe should be almost always) I haven't actually tested this yet, but hope to soon. JavaFX was designed to be independent of the JDK (though maybe now for a smaller range of versions) and having a little more flexibility here should make upgrades less painful. | 05:09:47 |
| 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 hate the JFX entangled into the JDK build thing
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 hate the JFX entangled into the JDK build thing
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 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 |
