Hello, we're testing Gradle 9-RC1 internally where we're still on `2.0.21` (don't ask) which is fail...

# gradle

[Hugo Costa]

Hello, we're testing Gradle 9-RC1 internally where we're still on 2.0.21 (don't ask) which is failing with

java.lang.NoSuchMethodError: 'org.gradle.api.provider.Provider org.gradle.api.provider.Provider.forUseAtConfigurationTime()'
	at org.jetbrains.kotlin.gradle.plugin.internal.ConfigurationTimePropertiesAccessorG6.usedAtConfigurationTime(ConfigurationTimePropertiesAccessorG6.kt:19)
	at org.jetbrains.kotlin.gradle.plugin.internal.ConfigurationTimePropertiesAccessorKt.usedAtConfigurationTime(ConfigurationTimePropertiesAccessor.kt:49)
	at org.jetbrains.kotlin.gradle.utils.FileUtilsKt.getLocalProperties(fileUtils.kt:145)
	at org.jetbrains.kotlin.gradle.internal.properties.PropertiesBuildService$Companion$registerIfAbsent$1.execute(PropertiesBuildService.kt:168)
	at org.jetbrains.kotlin.gradle.internal.properties.PropertiesBuildService$Companion$registerIfAbsent$1.execute(PropertiesBuildService.kt:167)

Just want to confirm - is this a failure you'd expect in the gradle85 variant?

[Hugo Costa]

Understood - we have a barebones test that is not giving the required metadata to the Kotlin Gradle Plugin to understand that it should use the gradle85 variant. By manually removing main it works

[Hugo Costa]

Although, could it be that the metadata for 9 is so different that the Gradle plugin opts to go for main instead of gradle85 , and that's what's causing us the issue?

[tapchicoma]

2.0.21 is not compatible with Gradle 9

[tapchicoma]

2.1.21 should work in most cases

[Hugo Costa]

Managed to make it work 🙂

[Hugo Costa]

(just running a sample project with little to no code)

[Hugo Costa]

the issue is we use GradleRunner and we weren't specifying what version of Gradle it is running, so the Kotlin Gradle Plugin was defaulting to main

[Hugo Costa]

but yeah, we're definitively not launching this until I get 2.1.21+ as the only version of Kotlin inside the company. Biggest issue is that you dropped support for Kotlin 1.4 targetCompatibility. You can imagine how this is a problem 💀

[tapchicoma]

https://kotlinlang.org/docs/whatsnew22.html#flexibility-to-configure-different-compiler-versions-from-kotlin - have you seen it?

[Hugo Costa]

I assume the removal of the KOTLIN_1_4 happened just on the gradle plugin, the idea here is that for whatever packages I need that compatibility, I could set it to 2.0.21 and it'd just work?

[tapchicoma]

yes, and pass -language-version 1.4 via freeCompilerArgs

[tapchicoma]

though there are caveats regarding compiler plugins - there are not supported well in such a case

[Hugo Costa]

Anyway, the heavy lift it would be on our side to allow more than one 2.x package would kill us (we have a custom dependency management setup that's almost older than me), I prefer to force the teams to just upgrade to Kotlin 2.x

[Hugo Costa]

but this is certainly a very good feature, wish I could use it!

[tapchicoma]

I assume the removal of the KOTLIN_1_4 happened just on the gradle plugin

Also we are working on restoring some DSL support for old values that could be used with older Kotlin compiler versions

[Hugo Costa]

Ok, this did seem a little too good to be true - GradleRunner , with a particular Gradle version, will attempt to download it, so it works well locally, but not remotely where it is network jailed.

Yahor, there is no way for me to specify the Gradle variant right? By default, it can't find an optimal one, it defaults to main 😕. Would it be possible to change it from main to whatever is the latest one?

[Hugo Costa]

According to this (let's imagine it's the 2.0.21 where gradle85 likely said what 813 says here), should 9.0.0 use gradle85?

[tapchicoma]

gradle8.13 should be used with Gradle 9.0. You could provide directly to the test https://repo1.maven.org/maven2/org/jetbrains/kotlin/kotlin-gradle-plugin/2.2.0/kotlin-gradle-plugin-2.2.0-gradle813.jar via GradleRunner.withPluginClasspath

[tapchicoma]

BTW why are you stuck on older Kotlin versions?

[Hugo Costa]

We initially allowed people to select whatever version of Kotlin they wanted. This has now translated into some core libraries using Kotlin 1.3/compiling with --languageVersion 1.4, and an untold amount of customers that also use it. If we elevate the number, a lot of these packages will need to be fixed. It's hard to get these things done at such a scale. You do not want to know how difficult it was (still ongoing) to get people off JDK8.

[tapchicoma]

It's hard to get these things done at such a scale

In theory you could try to look into OpenRewrite rules such mass migration 🤔

[Hugo Costa]

Yeah, we have an internal tool that uses GenAI + OpenRewrite recipes, but it's just way too many teams spread all over the world, a lot of red tape to force people to use it. For Kotlin 2.x, we're trying to keep everyone on the same version across the company, but as you've seen, we haven't been able to move past 2.0 because of the higher target compatibility in 2.1 + the Gradle 7 incompatibility (which I hope to address, I already migrated a few central ones myself)