Update remotejdk_21 to Zulu 21.0.12

[davido]

Bump the remotejdk_21 pins from Zulu 21.46.19 (OpenJDK 21.0.9) to Zulu 21.52.15 (OpenJDK 21.0.12) for all six platforms.

Zulu 21.0.9 lacks the backport of JDK-8341779 (reading type-use annotations on type-variable bounds from class files). This makes recent Error Prone report false positives such as
NullArgumentForNonNullParameter on documented Guava API usage, e.g. Iterables.getFirst(iterable, null), when compiling with the Java 21 toolchain; see google/error-prone#5436 for the analysis by the Error Prone maintainers.

Note that Azul changed the layout of the macOS tar.gz archives after 21.0.9: they now contain a macOS application bundle with the JDK under Contents/Home instead of a flat JDK image (the Zulu 25 macOS archives are still flat). The strip_prefix of the two macOS entries therefore descends into Contents/Home.

SHA-256 checksums are taken from the Azul metadata API; the linux_x64 and macosx_x64 artifacts were additionally downloaded and verified locally.

Fixes #369

[hvadehra]

Note that Azul changed the layout of the macOS tar.gz archives after 21.0.9: they now contain a macOS application bundle with the JDK under Contents/Home instead of a flat JDK image (the Zulu 25 macOS archives are still flat). The strip_prefix of the two macOS entries therefore descends into Contents/Home.

fwiw, it seems like this was always the case, but there used to be bin,lib, etc symlinks from the root dir into Contents/Home which are not present in the new release.

[hvadehra]

I'm working on a fix the failing test to support this new release

[hvadehra]

I'm working on a fix the failing test to support this new release

Done in ed021f9 , please rebase to HEAD.

[davido]

Done in ed021f9 , please rebase to HEAD.

Rebased onto HEAD (on top of ed021f9) — thanks for fixing the check script.

Also thanks for the symlink correction: you're right that the bundle layout was always there and it's the root-level bin/lib symlinks into Contents/Home that are gone in the new release. I've updated the commit message accordingly; the diff itself is unchanged (same six pins, same checksums, same two _STRIP_PREFIX_OVERRIDES entries).

PTAL.

[hvadehra]

I'm now having second thoughts about the strip_prefix change.

If we strip all the way to Contents/Home/ we are dropping contents that users may be expecting to be present. I admit it's unlikely those are needed within Bazel itself, since it would mean they'd have to patch the (generated) BUILD file to make use of it, but it's possible.

The (dropped) content itself doesn't seem like it would have much use within a Bazel build:

$ tar ztf zulu21.52.15-ca-jdk21.0.12-macosx_aarch64.tar.gz --exclude='*/Contents/Home*'
zulu21.52.15-ca-jdk21.0.12-macosx_aarch64/
zulu21.52.15-ca-jdk21.0.12-macosx_aarch64/Contents/
zulu21.52.15-ca-jdk21.0.12-macosx_aarch64/Contents/_CodeSignature/
zulu21.52.15-ca-jdk21.0.12-macosx_aarch64/Contents/_CodeSignature/CodeResources
zulu21.52.15-ca-jdk21.0.12-macosx_aarch64/Contents/MacOS/
zulu21.52.15-ca-jdk21.0.12-macosx_aarch64/Contents/MacOS/libjli.dylib
zulu21.52.15-ca-jdk21.0.12-macosx_aarch64/Contents/Info.plist

but I can't say for sure.

• libjli.dylib seems like it might be needed. Although there's also a Contents/Home/lib/libjli.dylib but with slightly different content.
• Could there be licensing / provenance requirements to have everything present?.

Might it be safer to insert the top-level symlinks instead?

[davido]

Reworked to the symlink approach you suggested, and it turns out to be the general fix. Now three commits:

1. Accept an ancestor strip_prefix in check_remote_jdk_configs — rather than reverting your bin-finding, this relaxes the comparison to also accept strip_prefix being an ancestor of the bin's parent. Covers both flat archives (equal) and the macOS bundle (root strip_prefix, bin/ under Contents/Home). Ordered first so every commit stays green on its own.
2. Update remotejdk_21 to Zulu 21.0.12 — keeps the full archive: strip_prefix is the archive root (uniform with every other platform), and patch_cmds/patch_cmds_win recreate the top-level bin, lib, … symlinks into Contents/Home. So Contents/MacOS/libjli.dylib, Info.plist and the code signature are all preserved.
3. Update remotejdk_25 to Zulu 25.0.4 — while checking, I found the 25.x line made the same change: Zulu 25.0.2 was the last macOS build with the top-level symlinks, and 25.0.4 drops them too. So this bump reuses the exact same mechanism (the two macOS-25 repos join _MACOS_BUNDLE_REPOS).

That's the argument for handling it this way rather than as a 21-specific tweak: it's not an Azul glitch in one release — they're dropping the (non-standard) root symlinks across lines, and Temurin/Corretto never had them, so this is just the standard macOS .jdk bundle layout. The patch_cmds handling is the general, future-proof fix.

I folded the 25.0.4 bump into this PR since it hits the identical change and shares the mechanism — happy to split it into a separate follow-up if you'd rather review the 21 bump alone.

Two caveats only CI can confirm: the patch_cmds → JDK-resolution path needs a macOS runner, and patch_cmds_win (PowerShell New-Item -ItemType SymbolicLink, needs Developer Mode) a Windows fetch. The check relaxation itself is pure bash.

PTAL.

[hvadehra]

1. I'm actually inclined to just revert the bin-finding change and go back to the earlier check
2. Let's not do the windows patching unnecessarily
3. Since this is the expected new state of things, I would suggest updating all macos zulu releases to the latest ones, and changing the _zulu_remote_jdk_repo function to return the patch commands in the macos case.

[davido]

Thanks, that all makes sense — working on it now. Plan:

1. Revert the bin-finding change in check_remote_jdk_configs back to the earlier wrapper-dir check.
2. Drop patch_cmds_win — macOS-only ln -s.
3. Move the symlink patch_cmds into _zulu_remote_jdk_repo (macOS case) so it's generated for every macOS Zulu repo, and bump each Zulu major (8/11/17/21/25) to its latest release, then regenerate the config list.

Will push once it's regenerated and green.

[hvadehra]

Mirroring requested at bazelbuild/bazel#30634 , once that's done we can proceed with this.