[FEATURE] Support running Gradle with JDK versions above Gradle's official support range

[JLLeitschuh]

Hear me out, this is currently already supported by Gradle, but this doesn't work when applying this action.

If you have a Gradle build that is entirely written in Kotlin, you can run that build on a JVM that is above the supported version range of Gradle.

For example, I currently have a Gradle build using Gradle 7.1.1 and 7.3.3 running on JDK 20, a version that Gradle 8.0 still doesn't officially support, but it's doing so without failure.

However, as soon as you apply this action, the JDK support is restricted to the range of versions that Gradle officially supports. That's because Gradle compiles groovy script files with the current JDK, which generates a class file with the JDK version header. Then when Gradle attempts to execute that file, it blows up, stating that class files of that version aren't supported.

The best way that this could be fixed by this plugin would be to either:

1. Change the init scripts to use Kotlin instead of Groovy, which will compile to class files with lower bytecode compatibility
2. Add support for an option to disable adding the init script to the environment.

That way, if you apply this plugin, you can still take advantage of the rest of the features, like the great caching support, but you can still run on much higher versions of the JDK than the version of Gradle being used supports.

When is this needed: primarily when developing Gradle plugins.

Show me an example

Gradle build runs fine on JDK 20, even though Gradle's official documentation states that no version of Gradle supports it.

• https://github.com/JLLeitschuh/ktlint-gradle/actions/workflows/build-and-check.yml?query=branch%3Amain

Example of a build where applying this action breaks the build due to the class file incompatibility:

• Optimize CI a bit JLLeitschuh/ktlint-gradle#574

[ZacSweers]

Alternatively I'd love to disable this init behavior in this case, unless it's crucial to the execution of the action

[bigdaz]

1. Change the init scripts to use Kotlin instead of Groovy, which will compile to class files with lower bytecode compatibility

@JLLeitschuh If the init-script was written in Kotlin, how would you support older versions of Gradle? The way it works now, the init-script is written without any knowledge of which Gradle versions will be executed in a workflow.

2. Add support for an option to disable adding the init script to the environment.

In this case you'd lose the build results in the Job Summary, as well as the upcoming dependency-submission support (which will also leverage an init-script).

Perhaps you could combine these 2 options, by allowing a workflow to explicitly opt-in to Kotlin-based init-scripts. We'd need to maintain 2 different init-script versions, and possibly we'd want to migrate more of the build-results-capture functionality to Java to enable reuse.

Would you be interested in contributing a PR for this feature?

[JLLeitschuh]

@JLLeitschuh If the init-script was written in Kotlin, how would you support older versions of Gradle? The way it works now, the init-script is written without any knowledge of which Gradle versions will be executed in a workflow.

Hrm... I guess the tradeoff here is forwards compatibility vs backwards compatibility. Maybe this should be considered a bug in Gradle that it doesn't have implicit forward compatibility

[JLLeitschuh]

@bigdaz could we do loose version checking of the Gradle properties file. If the version is in a range that supports kotlin files, drop a kotlin script, otherwise, drop a Groovy file?

If we can't determine the version, always fallback to a Groovy file.

Do you think this would work?

[bigdaz]

@bigdaz could we do loose version checking of the Gradle properties file. If the version is in a range that supports kotlin files, drop a kotlin script, otherwise, drop a Groovy file?

If we can't determine the version, always fallback to a Groovy file.

Do you think this would work?

It might work, but it could cause for projects that do CI runs with different versions of Gradle.
To start with, I'd make this an explicit opt-in via an action parameter. If it proves very useful, then we could consider making it automatic.

[bigdaz]

The setup-gradle action relies heavily on Groovy init-scripts, and thus can only execute on officially supported JDKs for the Gradle version being executed.