 | NixOS JVM | 121 Members |
| 27 Servers |
| NixOS JVM | 121 Members |
| 27 Servers |
| Sender | Message | Time |
|---|---|---|
| 16 Jul 2025 | ||
 msgilligan | It looks like there is an API that can give that info for many distributions: https://github.com/foojayio/discoapi | 07:43:14 |
| msgilligan | I opened an issue for the "JDK dashboard Utility": https://github.com/NixOS/nixpkgs/issues/425860 | 18:10:28 |
| msgilligan | I also set some of the metadata tags on this issue, let me know if I did that wrong. | 18:27:11 |
| 17 Jul 2025 | ||
 emily | they don't build their own JDKs, so this isn't really a comparable situation | 13:06:52 |
| emily | we already use Temurin as the "vanilla" binary build to bootstrap our OpenJDK source build, e.g. | 13:07:08 |
| emily | Temurin is "just" a vanilla-aiming OpenJDK build | 13:07:54 |
| emily | a distribution in itself | 13:08:01 |
| emily | it is standard for package collections, as distributors themselves, to compile their own OpenJDKs | 13:08:24 |
| emily | there is really not much magic in the build glue https://github.com/adoptium/temurin-build | 13:09:08 |
| emily | the value-add of Temurin is in providing the infra and testing and brand name, not the build logic | 13:09:37 |
| emily | which is why a separate Temurin source build makes no sense (either the Temurin build scripts are a good fit for us and we can use them in our OpenJDK source builds, or they would make the derivation less maintainable or less flexible and so we should keep driving the OpenJDK build on our own) | 13:10:35 |
| emily | the Temurin product is builds | 13:11:07 |
| emily | not sure if they even allow their trademark to be used for builds of OpenJDK that happen to use the same build scripts | 13:11:20 |
| emily | feel like the proliferation of near-identical OpenJDK distributions has led to a lot of confusion about what they actually are… | 13:12:19 |
 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 |