!aRKdLCkUeIFjRPZuJT:nixos.org

NixOS JVM

122 Members
27 Servers

Load older messages


SenderMessageTime
16 Jul 2025
@msgilligan:matrix.orgmsgilligan

e.g.

    corretto = {
      hasDefault = false;
      versions = [ "11" "17" "21"];
    };

and

    zulu = {
      hasDefault = true;
      versions = [ "11" "17" "21" "24"];
    };
06:51:34
@infinidoge:inx.moeInfinidoge 🏳️‍⚧️I believe there should be more info attached to lib.recurseIntoAttrs06:51:37
@msgilligan:matrix.orgmsgilligan 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
@msgilligan:matrix.orgmsgilliganWe should probably look at what SDKMAN! does: https://sdkman.io/jdks07:18:07
@msgilligan:matrix.orgmsgilliganNote that they are using Temurin as their default JDK.07:18:27
@msgilligan:matrix.orgmsgilliganAnd 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
@msgilligan:matrix.orgmsgilliganIt looks like there is an API that can give that info for many distributions: https://github.com/foojayio/discoapi07:43:14
@msgilligan:matrix.orgmsgilliganI opened an issue for the "JDK dashboard Utility": https://github.com/NixOS/nixpkgs/issues/42586018:10:28
@msgilligan:matrix.orgmsgilliganI also set some of the metadata tags on this issue, let me know if I did that wrong.18:27:11
17 Jul 2025
@emilazy:matrix.orgemilythey don't build their own JDKs, so this isn't really a comparable situation13:06:52
@emilazy:matrix.orgemilywe already use Temurin as the "vanilla" binary build to bootstrap our OpenJDK source build, e.g.13:07:08
@emilazy:matrix.orgemilyTemurin is "just" a vanilla-aiming OpenJDK build13:07:54
@emilazy:matrix.orgemilya distribution in itself13:08:01
@emilazy:matrix.orgemilyit is standard for package collections, as distributors themselves, to compile their own OpenJDKs13:08:24
@emilazy:matrix.orgemilythere is really not much magic in the build glue https://github.com/adoptium/temurin-build13:09:08
@emilazy:matrix.orgemilythe value-add of Temurin is in providing the infra and testing and brand name, not the build logic13:09:37
@emilazy:matrix.orgemilywhich 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
@emilazy:matrix.orgemily the Temurin product is builds 13:11:07
@emilazy:matrix.orgemilynot sure if they even allow their trademark to be used for builds of OpenJDK that happen to use the same build scripts13:11:20
@emilazy:matrix.orgemilyfeel like the proliferation of near-identical OpenJDK distributions has led to a lot of confusion about what they actually are…13:12:19
@infinidoge:inx.moeInfinidoge 🏳️‍⚧️Much better explanation than mine in the PR comments, my thoughts exactly13:15:08
@msgilligan:matrix.orgmsgilliganCould we use their AQAVit tests?15:30:41
@emilazy:matrix.orgemilypotentially; I'm not sure how computationally expensive they are or how hard they are to wire up15:37:48
@emilazy:matrix.orgemily 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
@emilazy:matrix.orgemily

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
@emilazy:matrix.orgemilyit 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 Hydra15:40:27
@emilazy:matrix.orgemily "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
@emilazy:matrix.orgemilyno 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 periodically15:42:00
@msgilligan:matrix.orgmsgilligan

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

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:matrix.orgmsgilligan

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

The individual working on it seems committed to doing it, so maybe we find out.

16:17:36

Show newer messages


Back to Room ListRoom Version: 6