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

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.

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.

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:

• OpenJDK
• GraalVM Community Edition

Second-tier:

• Temurin (because it's used for bootstrap)
• Zulu (because it's used on Darwin)

Community-supported:
Everything else (and if something isn't maintained it can be dropped)

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:

• OpenJDK
• GraalVM Community Edition

Second-tier:

• Temurin (because it's used for bootstrap)
• Zulu (because it's used on Darwin)

Community-supported:

• Everything else (and if something isn't maintained it can be dropped)

we use Zulu because we don't have a source build for OpenJDK/OpenJFX on Darwin. that should be easy to fix, but even ignoring that, the value-adds of Zulu over Temurin binaries are:

• aarch64-darwin support for JDK 8 – but JDK 8 will go EOL before Rosetta 2 makes using x86_64-darwin for old versions of Minecraft non-viable anyway
• OpenJFX support, but frankly few seem to care about OpenJFX and like I said making the source build work on Darwin shouldn't be hard

I think

• try to get openjdk and openjfx building with the Temurin bootstrap on Darwin
• failing that, just use Temurin on Darwin and don't support OpenJFX there
  would be sensible

I think

• try to get openjdk and openjfx building with the Temurin bootstrap on Darwin
• failing that, just use Temurin on Darwin and don't support OpenJFX there

would be sensible

In reply to @infinidoge:inx.moe
Also if Nixpkgs has some mechanism to give security warnings only if something isn't a dependency