 | NixOS JVM | 122 Members |
| 27 Servers |
| NixOS JVM | 122 Members |
| 27 Servers |
| Sender | Message | Time |
|---|---|---|
| 17 Jul 2025 | ||
 msgilligan | Another thing I would like to be able to do is develop native command-line tools that are built with GraalVM and contribute them to Nixpkgs. | 16:50:58 |
| msgilligan | I've also found that having an integrated OpenJFX sometimes solves build issues in various circumstances. (In theory this shouldn't be needed, but in practice it is.) | 16:52:50 |
| msgilligan | * So, my personal priorities ("itches I need to scratch" for other projects I'm working on) are:
And I also want to learn more about Nix and help the community in general, so that's why I want to make:
It's also relatively easy for a newcomer like me to help with updates on some of the binary distributions. And anything I can do to get improved JDK 24 or JDK 25 on | 16:53:16 |
 j4m3s | I seem to remember I encountered issues where the graalvm compiled binaries had some references to some jars in the graal derivation which meant it was pulled as a dependency. Kinda defeated the purpose of having small binaries :/ (that info might be outdated) | 16:53:37 |
| msgilligan | 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, I"m pretty sure 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. | 16:56:08 |
| msgilligan | * 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. | 16:56:29 |
| msgilligan | Keeping the Zulu packages up-to-date should not be that hard if we get slightly better tooling in place. I'm willing to help with that -- at least until we have an OpenJDK build for Darwin. | 17:00:19 |
| 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.orgIirc (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
| 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 |