Hey, folks! In my IntelliJ Platform Gradle Plugin, I've decided to bump the Gradle version from

8.14.3

to

9.0.0-rc-4

. When running integration tests against Gradle 8.x, the plugin fails on

java.lang.NoSuchMethodError

and

java.lang.NoClassDefFoundError

. In my code, I rely on

sequenceOf()

and

yield()

, whose signatures slightly changed in Kotlin 2.0:

sequenceOf()

* Exception is:
java.lang.NoSuchMethodError: 'kotlin.sequences.Sequence kotlin.sequences.SequencesKt.sequenceOf(java.lang.Object)'
	at org.jetbrains.intellij.platform.gradle.resolvers.path.ModuleDescriptorsPathResolver.<init>(ModuleDescriptorsPathResolver.kt:19)
	at Build_gradle.<init>(build.gradle.kts:53)

yield()

* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':signPlugin'.
....
Caused by: java.lang.NoClassDefFoundError: kotlin/coroutines/jvm/internal/SpillingKt
	at org.jetbrains.intellij.platform.gradle.tasks.SignPluginTask$arguments$1.invokeSuspend(SignPluginTask.kt:208)
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)

My first though was to build the Gradle plugin targeting Kotlin 1.8 (we support Gradle 8.5+) using:

kotlin {
    jvmToolchain(17)

    compilerOptions {
        apiVersion = KotlinVersion.KOTLIN_1_8
        languageVersion = KotlinVersion.KOTLIN_1_8
    }
}

but this didn't really help. Any ideas on how to deal with that?

Probably you'll need to set

coreLibrariesVersion

Ah, the joy of not using Java for a public plugin. 😄

The fact that

apiVersion

doesn't cover this is a major oversight IMO but I'll still have this over semi colons any time ;-)

You mean around semicolons? 😉 https://github.com/gradle/gradle/blob/e16096755271f495a1e4c4a9a1cbe13c104c03ac/pla[…]n/org/gradle/kotlin/dsl/plugins/dsl/KotlinDslCompilerPlugins.kt 🥲

Another inheritance from Java :-D It is like target compatibility. Java became sane and added

-release

. 🤷‍♂️

apiVersion is pretty much the same as Java's release

The big difference is that the Kotlin runtime lib is not bundled

> apiVersion is pretty much the same as Java's release > > I thought so too, but then why do you additionally need the

coreLibrariesVersion

to compile against the old API? 🤔

Because it's bonkers 🙃

Ah, so it wants to be like

-release

, but isn't, I see. :-)

There's no 1:1 mapping between the JVM and Kotlin flags. One has an execution environment and a bundled runtime. The other reuses the JVM execution environment and has an unbundled runtime. Kotlin also has compile-time requirements that are different from runtime (

languageVersion

). It's tempting to try to map the concept but I find it easier to look at them differently. Why there is both

apiVersion

and

coreLibrariesVersion

is a mistake IMO

@Martin I'm using

kotlin-dsl

which overrides on the task's level (ref) the

apiVersion

and

languageVersion

set via extension.

👍