| 17 Jul 2025 |
 msgilligan | And I want to make JDK 25 EA available -- at least as on overlay -- so I (and others) can begin testing things with JDK 25 and to help expedite support for JDK 25 GA when it is ready. | 17:03:06 |
 emily | I think just s/zulu/temurin/ for Darwin would be fine. I would be somewhat surprised if anyone cares much about OpenJFX on Darwin | 17:11:30 |
 j4m3s | In reply to @msgilligan:matrix.org
When I talk about GraalVM, I mean using native-image to generate binaries, but that is not all that GraalVM does. For the native-image case, if done properly, the binaries are stand-alone. But they are very large compared to a C binary. The advantage is they are standalone and start up quickly. Iirc (again, I could be wrong) nix looks for /nix/store references in binaries to infer runtime deps. So native-image compiled binaries are light, but since it brings the whole graalvm as a runtime deep, the whole thing is heavy. Even if compiled with --static, the issue is the string ref to graal | 17:11:42 |
| emily | (but if they do, then "make OpenJFX build on Darwin" should be a smaller task than "make OpenJDK build on Darwin") | 17:11:48 |
| emily | split outputs likely solve this | 17:12:05 |
| emily | well, or do you mean the JAR references are purely artificial and not used at runtime at all? | 17:12:19 |
| emily | in that case we can remove-references-to | 17:12:23 |
| j4m3s | Oh really there's a feature tu remove refs ? I skimmed through the manual and didnt find any ;_; | 17:15:15 |
| j4m3s | (Sorry I kinda hijacked the discussion 😅) | 17:15:39 |
 Infinidoge 🏳️⚧️ | I still don't understand $out/nix-support to be honest | 17:15:42 |
| Infinidoge 🏳️⚧️ | That's a directory of witchcraft I seek to understand | 17:15:53 |
| emily | it just replaces the paths with /nix/store/eeeeeeee…-abc/… | 17:16:48 |
| emily | so it's a pretty heavy hammer | 17:16:53 |
| msgilligan | Well, I have two projects using OpenJFX. Generally, it can be loaded via Maven and doesn't need to be bundled with the JDK, but there are some corner cases that pop-up where having it bundled in the JDK resolves the issue. (And I think some of these corner cases are caused by Nix) | 17:16:54 |
| emily | ideally you get the tool to not output those false references to begin with | 17:16:59 |
| msgilligan | * Well, I have (at least) three projects using OpenJFX. Generally, it can be loaded via Maven and doesn't need to be bundled with the JDK, but there are some corner cases that pop-up where having it bundled in the JDK resolves the issue. (And I think some of these corner cases are caused by Nix) | 17:17:12 |
| emily | we could still package it in Nixpkgs, and if we absolutely need it bundled into a JDK executable we can use jlink, which I believe should work with Temurin binaries too | 17:18:19 |
| emily | though I'd hope we could solve the cases where that appears necessary | 17:18:28 |
| emily | unless they killed jlink too :) | 17:19:00 |
| Infinidoge 🏳️⚧️ | Amazing, nix-support seemingly has no results in the Nix manual, and 6 entirely different results for things other than remove-references-to | 17:19:42 |
| emily | like bundling in the JDK is explicitly deprecated
As of JDK 11, the javafx.* modules are no longer included as part of the JDK. They are now distributed separately as a standalone, unbundled release of OpenJFX. They are available either as maven artifacts for use with maven/gradle or as a standalone SDK that includes jmod files for use with jlink.
| 17:19:43 |
| emily | nix-support isn't related to move-references-to | 17:20:03 |
| emily | nix-support is just files that stuff in Nixpkgs stdenv etc. consume | 17:20:11 |
| emily | not sure Nix cares about it at all | 17:20:14 |
| Infinidoge 🏳️⚧️ | * Amazing, nix-support seemingly has no results in the Nix manual, and 6 entirely different results for things other than remove-references-to in the Nixpkgs manual | 17:20:32 |
| Infinidoge 🏳️⚧️ | The 6 references are in the nixpkgs manual (edited previous message) | 17:20:47 |
| Infinidoge 🏳️⚧️ | So it isn't documented in the place where it's most useful anyways | 17:20:56 |
| msgilligan | Yeah, but it's non-trivial to build your app correctly pulling JavaFX from Maven. I do it correctly in my apps, but I think there are paying Zulu customers who don't know how to do it or have legacy code that is hard to update. | 17:23:59 |
| msgilligan | I have run into some Nix-specific JavaFX issues that I was able to workaround by using the bundled JavaFX. | 17:25:16 |
| emily | to be clear, I'm not saying "use it from Maven". | 17:27:34 |
