[rcombs]

Let collaborators use the same project with different installed JDKs. The wrappers select Gradle 8.14.6 on Java 11–16 and Gradle 9.8.1 on Java 17 and newer, without rewriting project configuration or installing another JDK. Add POSIX/Windows launcher regression coverage and migration documentation.

The stock Gradle 9.8.1 wrapper refresh, automatic selection, tests/CI, and documentation remain separate commits.

Validation

Tested against episode 1 of the GJM ITEM project.

🤖 Codex

[astiob]

The message of the “Refresh stock wrapper files for Gradle 9.8.1” commit doesn’t explain what “legacy” means or what is “identical” to what. It should probably be moved after “Add Gradle 9.8.1 with automatic selection for the installed Java” or merged with it, like in #8.

Actually: judging by wrapper_compatibility.py having only one hash, is gradle-wrapper.jar identical to gradle-wrapper-legacy.jar? But it’s the Gradle 9 wrapper, right? Why is the legacy one not the 8 wrapper?

Consider renaming the old wrapper files to legacy in one commit and adding the new ones in a separate commit. This will break building on that one commit but will enable Git’s rename detection to build a continuous history for the legacy files.

[astiob]

Oh, so the magical Gradle selection is done by directly modifying gradlew? This seems extremely fragile, since a regular Gradle wrapper update will undo this and the user performing the update will be none the wiser (since nobody checks the diff for the wrapper, what with it normally being a full copy of an upstream file).

This also means downstream projects must use specifically the gradlew scripts from the SubKt repo rather than official Gradle ones, which is unintuitive per se. Indeed, it’s precisely only downstream projects that must do this, since SubKt’s own wrapper doesn’t matter when it’s used as a plugin.

I don’t suppose there’s any other way?

I see this is documented in the last commit, but perhaps the documentation could be even clearer/more explicit/more eye-catching. Two items are key:

• If a downstream project wants to work on Java 16− and 25+ simultaneously, it must take its Gradle wrapper from the SubKt repo and avoid the official Gradle’s wrapper command.
• When the Gradle wrapper is updated in the SubKt repo, SubKt’s added custom blocks of code must be kept.

Alternatively—or indeed, in addition,—we could advise users to just install Gradle system-wide and use that instead of the wrapper, with a promise that SubKt is guaranteed to work on Gradle 8 (on Java 11–24) and on Gradle 9 (on Java 17+).

[astiob]

FWIW a completely different approach could be to enforce Java 17 but let Gradle 9 auto-download it, which is possible if I understand https://docs.gradle.org/8.14.6/userguide/gradle_daemon.html#sec:daemon_jvm_criteria correctly. But of course, this would (?) mean that users with, say, Java 25 would get an extra copy of Java they don’t really need. I can’t say I really like that.