Repository navigation
Set the JDK in one place: Temurin 25 for Gradle, CI and bytecode - #80
Merged
Merged
Conversation
The JDK version was written in four places: the toolchain and source/target level in app/build.gradle, and java-version in both CI jobs. The JVM running Gradle was whatever JAVA_HOME happened to be. Locally that could be 21 while CI ran 26. gradle/gradle-daemon-jvm.properties (written by `./gradlew updateDaemonJvm`) now sets the version, at 26 as before. Gradle runs its daemon on that JDK, and downloads it through the Foojay URLs in the file when no match is installed. app/build.gradle reads the same toolchainVersion for the toolchain and source/target level. Both CI jobs read it before setup-java, so each job installs that JDK and Gradle downloads nothing. The CI checkout now runs before setup-java so the file is there to read. setup-java now installs Temurin rather than Corretto. That is the build Gradle downloads locally, and the one ShakeyTrollApk's CI uses. The wrapper moves from 9.6.1 to 9.8.2, with its checksum, scripts and jar regenerated by the 9.8.2 wrapper task. All four wrapper files are now byte-identical to ShakeyTrollApk's. Renovate would have proposed this bump now that gradle-wrapper is enabled; it is done here so the two repos move together. Verified locally with the daemon on Temurin 26.0.2.1: testDebugUnitTest, jacocoTestReport, assembleRelease, assembleDebug, lintRelease and lintDebug. Latency/performance: none. Only build configuration changes. javac targets the same Java 26 level, R8 desugars to the same API 30 target, and no runtime code is touched. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KYjVHxLdAHQsqkM5haaUZQ
gradle/gradle-daemon-jvm.properties, regenerated with `./gradlew updateDaemonJvm --jvm-version=25`, now names 25. That one line already sets the JVM Gradle runs on, the JDK both CI jobs install, and the toolchain and source/target level in app/build.gradle, so all of them move together. 26 was a six-month release whose updates stopped when 27 shipped. No language feature from it is used here, so staying on it bought nothing and meant a JDK bump every six months. 25 is supported long term. The comments and docs that named 26 now say 25: the toolchain and JaCoCo comments in app/build.gradle, the builtInKotlin note in gradle.properties, CLAUDE.md and README.md. Lint still reads up to class file 70, so the "check lint before going past 26" warning stays as it is. JaCoCo 0.8.16 stays; 0.8.14 was the first release with official support for class file 69. Verified locally: the daemon runs on Temurin 25.0.5, compiled classes are major version 69, testDebugUnitTest passes (314 tests), and lintRelease is green with no "Unsupported class file" messages. Latency and performance: none at runtime. D8 turns the bytecode into DEX whatever the class-file version, and no source changed. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KYjVHxLdAHQsqkM5haaUZQ
CI's setup-java installs Temurin, and the foojay URLs in gradle/gradle-daemon-jvm.properties already download Temurin. But the file named no vendor, so locally any JDK 25 already installed, such as Corretto or Zulu, satisfied both the daemon and the compile toolchain. `./gradlew updateDaemonJvm --jvm-version=25 --jvm-vendor=adoptium` now writes toolchainVendor=ADOPTIUM, and app/build.gradle reads it for the toolchain, so the daemon, the compiler and CI are the same build of the same JDK. foojay lists no Temurin 25 for Windows on ARM64, so that one download URL drops out. No supported dev setup uses it. Latency and performance: none at runtime. Build configuration only. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KYjVHxLdAHQsqkM5haaUZQ
Without --jvm-vendor, rerunning updateDaemonJvm as README.md said would drop the toolchainVendor line and the Temurin pin with it. The CLAUDE.md paragraph is rewrapped to the file's width. Latency and performance: none. Docs only. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KYjVHxLdAHQsqkM5haaUZQ
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
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.
What
The JDK is now set once, in
gradle/gradle-daemon-jvm.properties, at Temurin 25 (the current LTS). That one file now decides:app/build.gradlereadstoolchainVersionandtoolchainVendorfrom the same file.build.ymlreadtoolchainVersionbeforesetup-java, so CI installs the same JDK and Gradle downloads nothing.Before this, the version was written in four places, and the daemon ran on whatever
JAVA_HOMEwas. That could be 21 locally while CI ran 26.Commits
--jvm-vendor=adoptium.The same setup goes into ShakeyTrollApk and torrtv in parallel PRs.
Verification
Run locally:
testDebugUnitTestpasses (314 tests).lintReleaseis green with no "Unsupported class file" messages.Latency and performance
None at runtime. This is build configuration only: D8 turns the bytecode into DEX whatever the class-file version, and no app source changed.
Generated by Claude Code