NixOS JVM | 122 Members | |
| 27 Servers |
| Sender | Message | Time |
|---|---|---|
| 16 Jul 2025 | ||
| e.g.
and
| 06:51:34 | |
| I believe there should be more info attached to lib.recurseIntoAttrs | 06:51:37 | |
and I'm including - and _ as a prefix in some versions as there is currently no consistent mechanism for concatenating name to version. e.g. zulu21, but temurin-bin-21 and graalvmPackages.graalvm-oracle_17 | 06:54:17 | |
| We should probably look at what SDKMAN! does: https://sdkman.io/jdks | 07:18:07 | |
| Note that they are using Temurin as their default JDK. | 07:18:27 | |
| And of course, what I would like to be able to do is to view the versions of each Nixpkgs JDK and display it next to the latest version available for that JDK. We have updaters for some of the JDKs that will pull the latest versions from a server. | 07:42:33 | |
| It looks like there is an API that can give that info for many distributions: https://github.com/foojayio/discoapi | 07:43:14 | |
| I opened an issue for the "JDK dashboard Utility": https://github.com/NixOS/nixpkgs/issues/425860 | 18:10:28 | |
| 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 | ||
| they don't build their own JDKs, so this isn't really a comparable situation | 13:06:52 | |
| we already use Temurin as the "vanilla" binary build to bootstrap our OpenJDK source build, e.g. | 13:07:08 | |
| Temurin is "just" a vanilla-aiming OpenJDK build | 13:07:54 | |
| a distribution in itself | 13:08:01 | |
| it is standard for package collections, as distributors themselves, to compile their own OpenJDKs | 13:08:24 | |
| there is really not much magic in the build glue https://github.com/adoptium/temurin-build | 13:09:08 | |
| the value-add of Temurin is in providing the infra and testing and brand name, not the build logic | 13:09:37 | |
| 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 | |
| the Temurin product is builds | 13:11:07 | |
| 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 | |
| feel like the proliferation of near-identical OpenJDK distributions has led to a lot of confusion about what they actually are… | 13:12:19 | |
| Much better explanation than mine in the PR comments, my thoughts exactly | 13:15:08 | |
| Could we use their AQAVit tests? | 15:30:41 | |
| potentially; I'm not sure how computationally expensive they are or how hard they are to wire up | 15:37:48 | |
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 | |
| 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 | |
| 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 | |
| "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 | |
| 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 | |
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 | |
The individual working on it seems committed to doing it, so maybe we find out. | 16:17:36 | |