Repository navigation
Run the Gradle daemon on any JDK 21 and download it from Adoptium - #2234
Merged
mpretty-cyro merged 3 commits intoOct 7, 2026
Merged
mpretty-cyro merged 3 commits into
mpretty-cyro merged 3 commits into
Conversation
The daemon JVM was pinned to JetBrains 21, fetched through api.foojay.io package-id redirects. foojay stopped serving those ids (foojayio/discoapi#165), and CI's setup-java Temurin 21 doesn't meet a JetBrains criterion, so every CI build failed provisioning the daemon before it started. Drop the vendor so any JDK 21 runs the daemon: CI's Temurin 21 is used as is, and locally Android Studio's JBR 21 still is. For machines with no JDK 21, the Linux/macOS/Windows URLs now go straight to Adoptium's API instead of through foojay; FreeBSD/Unix keep foojay, as Adoptium has no builds for them. Re-running updateDaemonJvm overwrites the file.
mpretty-cyro
marked this pull request as ready for review
October 7, 2026 22:47
The api.adoptium.net 'latest' URLs would hand a different JDK to a fresh machine whenever Adoptium publishes a 21.x update. Point each platform at the 21.0.12.1+1 release asset instead, so a provisioned daemon JDK only changes when this file does.
Bilb
reviewed
Oct 7, 2026
The previous commits edited gradle-daemon-jvm.properties by hand, so running updateDaemonJvm (to move to a newer JDK, say) would have put the JetBrains vendor and foojay URLs back. Set languageVersion and the Temurin download URLs on the updateDaemonJvm task instead, leaving the vendor unset; the properties file is again plain generated output, and regenerating it reproduces it exactly. Adoptium has no FreeBSD or other Unix builds, so those platforms get the Linux ones. That matches what the generated foojay entries did (FREE_BSD/UNIX shared the Linux package ids), and those ids now return 400 as well.
Bilb
approved these changes
Oct 7, 2026
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
2 participants
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.
Every Android CI run currently fails before Gradle starts:
gradle/gradle-daemon-jvm.propertiespins the Gradle daemon JVM to JetBrains 21 and downloads it through api.foojay.io package-id redirects. foojay stopped serving some of those ids (foojayio/discoapi#165, which reports the same JetBrains 21 ids returning 400). CI installs Temurin 21 withsetup-java, but that doesn't meet a JetBrains criterion, so Gradle tries the foojay download and fails.This drops the vendor, so any JDK 21 can run the daemon: CI's Temurin 21 is used as is with nothing to download, and locally Android Studio's JBR 21 still is. For a machine with no JDK 21, the Linux, macOS and Windows URLs now point straight at the Temurin 21.0.12.1+1 release assets that Adoptium (the Eclipse Foundation project that builds Temurin) publishes in
adoptium/temurin21-binaries, instead of going through foojay, which only indexes vendors' downloads. They're pinned to that release rather than Adoptium'slatestendpoint, so a provisioned daemon JDK only changes when this file does. FreeBSD and Unix get the Linux builds, as Adoptium has no builds for them; that matches the generated foojay entries, which used the Linux package ids for those platforms (and those ids return 400 now too). The vendor pin came in with #1923 with no stated reason; if it was wanted, say and I'll restore it with JetBrains' own download URLs instead.The
jvmToolchain(21)used for compilation has no vendor and the foojay resolver plugin stays; with a JDK 21 installed it never downloads.These settings live on the
updateDaemonJvmtask inbuild.gradle.kts(JDK version, no vendor, the pinned URLs), sogradle-daemon-jvm.propertiesstays plain generated output: running./gradlew updateDaemonJvmreproduces it exactly, and moving to a newer JDK is a change to that task.Tested: all six pinned release URLs resolve (200).
./gradlew helpwith a fresh daemon starts on the local JDK 21 with the edited file. The local machine only has JetBrains' JDK 21, so this PR's own CI run is what shows a non-JetBrains JDK 21 being accepted.