java: default to Temurin, keep Azul as the fallback - #305
Merged
Conversation
Temurin is the most-used OpenJDK build by a wide margin (308M docker pulls vs Zulu's 30M) and api.adoptium.net is a documented, versioned API. Azul's is a WordPress admin-ajax endpoint that returns 6.2MB in ~9s and, when it hands back anything but JSON, panics the whole run - that alone accounts for a chunk of our red CI. Adoptium doesn't publish the older feature releases though, so java@14 would 404. Fall back to Azul when the default can't satisfy a version, which keeps java@14 and the README examples working. An explicit -azul/-tem is left alone. Also fetch all available releases instead of just LTS + newest, so java@20 resolves at all, and take the lts tag and the offline fallback list from the API rather than a hardcoded [8, 11, 17, 21] that had gone stale. That's 13 versions instead of 6, so the requests now run concurrently rather than one after the other.
An unreachable api.adoptium.net comes back as an empty download list rather than an error. A versioned request already coped - nothing matches, so Azul takes over - but a bare `java` has no version to check against and fell straight through to an empty list. Azul used to be the default, so that case never had a way to fail before this branch; treat empty as unsatisfiable too. The fallback itself had no coverage: the existing java tests only exercise .java-version / .sdkmanrc parsing. Pin the default distribution, that the fallback name still resolves, and has_matching_version around the cases that drive it - java@14 missing from Adoptium, an empty list, and downloads with no parseable version.
…n-default-distribution
…serve `java@-jdk+jre` is in the README and the help output, and it has been broken for a while - on main too, so this is not fallout from the Temurin switch. Three things had to line up: Adoptium publishes jre images and we threw them away, so keep them and let the image_type tag decide. `-jdk` parses into the distribution slot, because the syntax is shared with `java@-temurin`, so a name that is not a registered distribution is now read as the tag removal it was meant to be. And defaults are required tags, so a dropped one has to leave that set as well, or the request asks for jre while still demanding jdk and matches nothing. That gives `-jdk` real meaning, which the cache path did not know about - it is built from tags only, so `java` and `java@-jdk` shared a directory and a plain `java` could hand you a JRE with no javac. Distribution goes into the path now, which also stops `java@17-azul` and `java@17-temurin` aliasing. The Azul fallback was decided on version alone, but tags are applied later. Temurin carries none of the +fx/+headless/+sts that only Azul publishes, so `java@+fx` failed outright instead of falling back. Ask get_url_matches, the same predicate that makes the final call. While Azul is on the automatic path, drop the unwrap/expect too - admin-ajax.php answering with HTML should not panic a run Temurin could have served - and keep the Temurin list when the fallback comes back empty. Verified cold on Linux x86_64: java, java@-jdk, java@-jdk+jre, java@+fx, java@14 and java@-temurin all resolve, land in six distinct cache dirs, and only the JDK ones carry javac.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Switches the default JDK distribution from Azul to Temurin, and fixes the selection bugs that turned up while verifying it.
Why Temurin
Temurin is the most-used OpenJDK build by a wide margin (308M docker pulls vs Zulu's 30M) and
api.adoptium.netis a documented, versioned API. Azul's is a WordPressadmin-ajax.phpendpoint that returns 6.2MB in ~9s and, when it hands back anything but JSON, panicked the whole run - that alone accounted for a chunk of our red CI.Adoptium doesn't publish the older feature releases, so
java@14would 404. Azul stays as the fallback, which keepsjava@14and the README examples working. An explicit-azul/-temis left alone.Also fetches all available releases instead of just LTS + newest, so
java@20resolves at all, and takes the lts tag and the offline fallback list from the API rather than a hardcoded[8, 11, 17, 21]that had gone stale. That's 13 versions instead of 6, so the requests run concurrently rather than one after the other.Fixes that came out of it
java@-jdk+jrenever worked - it's in the README and help output, and it was broken onmaintoo, so this part isn't fallout from the switch. Three things had to line up: Adoptium publishes jre images and we discarded them;-jdkparses into the distribution slot because the syntax is shared withjava@-temurin; and defaults are required tags, so a dropped one has to leave that set or the request demands jre and jdk at once.Cache path ignored the distribution. Once
-jdkmeant something,javaandjava@-jdkshared a directory and a plainjavacould hand you a JRE with nojavac. Distribution is part of the path now, which also stopsjava@17-azulandjava@17-temurinaliasing (that one predates this branch).The fallback only checked the version, but tags are applied later. Temurin carries none of the
+fx/+headless/+ststhat only Azul publishes, sojava@+fxfailed outright instead of falling back. It now asksget_url_matches, the same predicate that makes the final call.Azul no longer panics on a bad response, and an empty fallback no longer discards a usable Temurin list.
Verification
161 unit tests pass. Verified cold on Linux x86_64 - each lands in its own cache dir, and only the JDK ones carry
javac:javajava@-jdkjava@-jdk+jrejava@+fxjava@14java@-temurinKnown gaps
needs_fallbackisn't unit-testable as written (the distributionhandleris a barefnfield), so that decision is only covered end-to-end.zuluisn't registered as an alias forazul, sojava@-zuluresolves to Temurin..sdkmanrcfiles spell it that way, so worth deciding before this lands.