 | NixOS JVM | 120 Members |
| 27 Servers |
| NixOS JVM | 120 Members |
| 27 Servers |
| Sender | Message | Time |
|---|---|---|
| 17 Jul 2025 | ||
 Infinidoge 🏳️⚧️ | Much better explanation than mine in the PR comments, my thoughts exactly | 13:15:08 |
 msgilligan | Could we use their AQAVit tests? | 15:30:41 |
 emily | potentially; I'm not sure how computationally expensive they are or how hard they are to wire up | 15:37:48 |
| emily | I expect it's the kind of thing that might be suitable for passthru.tests, to be manually run on an update, rather than blocking the build on Hydra | 15:38:11 |
| emily | marketing like "Validates runtimes by passing a wide variety of application test suites, ensuring compatibility and reliability." makes me worry that it'd be a whole ordeal where it wants to fetch a bunch of stuff from the internet and have all kinds of implicit dependencies and at best they make it easy by providing a Docker container we can't use or something. but I haven't looked into it at all, so it's possible that it would be easier than this | 15:39:03 |
| emily | it looks like it's one of the requirements for listing on https://adoptium.net/en-GB/marketplace, though that's not something that would likely be interesting for us in itself. apparently another requirement is the TCK, which if https://openjdk.org/groups/conformance/JckAccess/ is up to date is non-Free and involves Oracle bureaucracy, and so definitely can't be run on Hydra | 15:40:27 |
| emily | "It varies from several hours to several days, but on average it takes about a day to pass the full TCK cycle." from https://www.azul.com/blog/use-tck-testing-to-ensure-that-your-java-distribution-conforms-to-the-java-se-specification/ is also not the kind of thing we can put on Hydra | 15:41:03 |
| emily | no idea how long AQAvit(™) takes, but I'm guessing it's not exactly fast either. it may be the kind of thing that would have to be done out-of-band periodically | 15:42:00 |
| msgilligan |
Yeah. And I also have the impression getting AQAVit running under Nix would be non-trivial. I don't think it is something the Nix Java team should prioritize in the short-run and it's not something I see myself having the time or inclination to tackle. But it might be nice to have eventually. | 16:16:06 |
| msgilligan |
The individual working on it seems committed to doing it, so maybe we find out. | 16:17:36 |
| msgilligan | It seems like the core Nix Java team (however that is defined) should focus an a few JDKs as "first-tier" and a few more as "second-tier" and declare the rest as community supported. And this should be documented somewhere. Something like: First-tier:
Second-tier:
Community-supported: | 16:23:49 |
| msgilligan | It would be nice to see an OpenJDK build that works on Darwin and I believe there is an active PR to do this. If it can be done correctly, then Zulu could be "demoted" to community-supported. | 16:31:46 |
| msgilligan | I'm also wondering why Nix doesn't do what GUIX does and build OpenJDK n with OpenJDK n-1. I'm guessing this is because we don't have the bootstrap chain going back far enough to make this work? | 16:33:32 |
| msgilligan | * It seems like the core Nix Java team (however that is defined) should focus an a few JDKs as "first-tier" and a few more as "second-tier" and declare the rest as community supported. And this should be documented somewhere. Something like: First-tier:
Second-tier:
Community-supported:
| 16:34:13 |
 Alyssa Ross | Historically people have been resistant to long bootstraps in Nixpkgs because of the build times. (IMO we should do it anyway) | 16:34:20 |
| Alyssa Ross | Guix has bootstrappability as an explicit principle and we sadly dont | 16:34:40 |
| Infinidoge 🏳️⚧️ | Having been the one to remove most of the JDKs, the problem with bootstrapping is maintaining all of the components | 16:35:11 |
| Infinidoge 🏳️⚧️ | Most of the JDK steps were very unable to build I tried fixing them and at a certain point I just gave up | 16:35:46 |
| msgilligan | Yeah, not only does the whole chain need to be there, but it needs to be maintained. | 16:35:58 |
| Alyssa Ross | The flipside is it would be a lot easier to notice things that would break the old versions if they were in the critical path of the current version | 16:36:32 |
| msgilligan | I would really like to see full bootstrappability, but I guess that's not feasible in the short-run. | 16:36:59 |
| Alyssa Ross | So it wouldn't be as bad as maintaining old leaf versions | 16:37:03 |
| Infinidoge 🏳️⚧️ | Considering how difficult it is to actively maintain OpenJDK already without the bootstrap chain, I am very skeptical of the benefit | 16:37:36 |
| msgilligan | It seems like creating tools to make the current maintenance easier is probably one of the biggest return-on-investment strategies. The JDK Dashboard tool, auto-updaters, more and better passthru tests, for example. | 16:40:42 |
| Infinidoge 🏳️⚧️ | Yeah | 16:41:00 |
| Infinidoge 🏳️⚧️ | Also if Nixpkgs has some mechanism to give security warnings only if something isn't a dependency | 16:41:35 |
| emily | I think Graal is currently unmaintained in Nixpkgs FWIW | 16:42:14 |
| Infinidoge 🏳️⚧️ | Because a bootstrap chain can't break evaluation for an EOL JDK version, but also should warn | 16:42:24 |
| Infinidoge 🏳️⚧️ | * Because a bootstrap chain can't break evaluation for an EOL JDK version, but also should warn if it is tried to be used | 16:42:28 |
| emily | I would suggest focusing on OpenJDK and Temurin binaries for now and expanding if it turns out there's resources to spare. in particular, I believe Zulu on Darwin can go away | 16:42:58 |