Commit Graph
3 Commits
Author SHA1 Message Date
JMR-devandClaude Opus 5 3841f58c74 Put the whole toolchain on Java 24, and take Gradle to 9.7.1
Java was scattered across four numbers that nobody had chosen together: the
daemon ran on 25 (pinned in gradle-daemon-jvm.properties), CI installed 17, the
IDE was set to 25, and the app compiled to 17 bytecode. Now all four say 24.

24 rather than 25 because 25 is not reachable end to end. Kotlin 2.2.10 refuses
jvmTarget 25 outright -- "available targets are 1.8 ... 23, 24" -- so the app's
bytecode could never have joined a 25 toolchain, and "everything on the same
version" would have stayed false in the one place it is hardest to notice. 24 is
the highest number all four can actually hold. Checked, not assumed: D8 dexes
Java 24 class files, and R8 full mode minifies them, so the shipped artifact
builds on this too.

Floating where floating is native:

  - java-version: '24' -- setup-java resolves the newest 24.x at run time.
  - toolchainVersion=24 -- Gradle reports it as "Compatible with Java 24, any
    vendor", and provisions whatever 24.x it finds or downloads.

The Gradle wrapper deliberately does NOT float, because it cannot: distributionUrl
names one archive and distributionSha256Sum is the checksum of that exact file.
That pairing is the wrapper's integrity check, and it is the same reasoning the
workflows already apply to action SHAs. Set via `./gradlew wrapper`, not by hand,
so the checksum matches the URL.

Dependencies were audited against Google Maven and Maven Central rather than
guessed at, and almost everything was already current: AGP, the Compose BOM,
core-ktx, activity, lifecycle, navigation, work, datastore, media3, room,
documentfile, annotation, espresso, androidx-junit, junit and ktlint are all at
their newest stable. Only two had moved -- detekt to 2.0.0-alpha.6 and JaCoCo to
0.8.15 -- and both are here.

Kotlin stays at 2.2.10 and that is now recorded as a verified fact rather than a
warning: the AGP 9.3.1 POM declares kotlin-gradle-plugin 2.2.10 at runtime scope,
which is what AGP's built-in Kotlin actually compiles with. Android lint suggests
2.4.10 and taking that suggestion breaks the build unless KGP is also forced onto
the root buildscript classpath. agp, kotlin and ksp move together or not at all.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 14:42:41 -05:00
JMR-devandClaude Opus 5 f4962913e1 Correct the JDK claim, and finish the @UnstableApi propagation
Two things the first pass got wrong.

CLAUDE.md said "use a JDK 17-21, AGP 9 does not support 25+". That was carried
over from the sibling repo and is not true here: gradle-daemon-jvm.properties
pins toolchainVersion=25, so Gradle provisions and runs the daemon on Java 25
whatever JAVA_HOME says -- JAVA_HOME only picks the launcher. `gradlew --version`
prints both, and shows them differing on this machine right now. It also means
CI's java-version: '17' is not the JDK that compiles anything, and that the
daemon JVM is the same on a laptop as on a runner, which is a better guarantee
than the one the file claimed.

Marking ConversionDependencies @UnstableApi propagates to its callers, and
FakeFailures in androidTest calls it. That is a warning rather than an error in
Kotlin, and lint does not read the androidTest source set, so the previous
commit compiled clean while leaving one file inconsistent with the very pattern
it described. Marked now.

Left alone deliberately: gradlew.bat. The new `*.bat text eol=crlf` attribute
governs how it is checked out from here on, which is the point of adding it,
and the file already has CRLF in both the tree and the index. Rewriting the
stored bytes of the wrapper script to prove the attribute works is not this
branch's business.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-22 14:24:16 -05:00
JMR-dev 18ae2cff80 initial commit 2026-08-19 17:29:15 -05:00