I have this task in my `build.gradle` ```compileKotlin { kotlinOptions { jvmTarget = Jav...

# gradle

[Vitali Plagov]

I have this task in my build.gradle

compileKotlin {
    kotlinOptions {
        jvmTarget = JavaVersion.VERSION_11
    }
}

The IDEA warns me that kotlinOptions is deprecated. I can’t find the option how to replace this with a proper syntax. Can anyone please help me? Gradle 7.2, Kotlin 1.8.0

[mudasar187]

withType<KotlinCompile> {
    kotlinOptions.jvmTarget = "17"
}

inside tasks {} definition

[mudasar187]

Depend if you have Kotlin or Groovy based build file

[Vitali Plagov]

I have a Groovy based file. I don’t have the tasks {} definition. Tasks that I have in the build script are defined on the root level

[mbonnin]

Both are basically doing the same thing.

[mbonnin]

https://kotlinlang.org/docs/gradle-compiler-options.html#how-to-define-options mentions compilerOptions , I'd go with that

[mudasar187]

@Vitali Plagov I have

compileKotlin {
    kotlinOptions.jvmTarget = '17'
}

In another project without warning

[mbonnin]

It might be that the IDEA warning cannot detect all possible syntax

[Vitali Plagov]

@mudasar187 thank you, that removed the deprecation warning.
Though, it looks very much the same

[mbonnin]

But if it complains about kotlinOptions in one of the syntax above, I'm pretty sure it should be the case for all other syntaxes that use kotlinOptions , whether you use Groovy, Kotlin, withType or compileKotlin , etc...

[Vitali Plagov]

Indeed

[Vitali Plagov]

Could be an IDEA issue or a bug?

[mbonnin]

Sounds like an IDEA issue

[mbonnin]

But in Groovy TBH it's really hard to do this kind of inspections

[mbonnin]

This is one of the reasons I like Kotlin build scripts better

[Vitali Plagov]

We have a very simple gradle build script, so I still didn’t find enough justification to convert it to the Kotlin syntax 🙂

[tapchicoma]

Heh, it is deprecation of this method you are seeing:

fun kotlinOptions(fn: Closure<*>) { ... }

Generally it is not related to compilerOptions, but still you should to migrate to them. kotlinOptions will be deprecated once IDEA will have proper support for migration from kotlinOptions

[mbonnin]

Ah ! So the syntax was important actually. Thanks, TIL!

[Vitali Plagov]

Which option would be better instead of the deprecated one then?

[Vitali Plagov]

compileKotlin {
    kotlinOptions.jvmTarget = '17'
}

this?

[tapchicoma]

I would say better to use:

compileKotlin {
    compilerOptions.jvmTarget = org.jetbrains.kotlin.gradle.dsl.JvmTarget.JVM_17
}

[mudasar187]

@tapchicoma is this for groovy based or also for Kotlin DSL?

[tapchicoma]

Kotlin DSL will be:

tasks.named<org.jetbrains.kotlin.gradle.tasks.KotlinJvmCompile>("compileKotlin") {
    compilerOptions.jvmTarget.set(org.jetbrains.kotlin.gradle.dsl.JvmTarget.JVM_17)
}

[tapchicoma]

obviously will look better with imports 🙂

[Vampire]

Is there no type-safe accessor?
So tasks.compileKotlin { compilerOptions... } for Kotlin DSL.

[tapchicoma]

there is, but it uses internal KGP task type which we are planning to hide 🤔

[tapchicoma]

probably still ok

[Carter]

Is there another variant of this for when using the Kotlin Multiplatform Gradle plugin?

When just trying this as-is, I get

* What went wrong:
Task with name 'compileKotlin' not found in project ':app'.

[mbonnin]

On multiplatform, compile tasks have the target name inside like compileKotlinJvm or so. You can certainly apply to all tasks. Maybe something like this:

tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile>() {
    compilerOptions.jvmTarget.set(org.jetbrains.kotlin.gradle.dsl.JvmTarget.JVM_17)
}

[mbonnin]

Modulo lazy configuration, etc...

[Vampire]

Please don't use tasks.withType<...>() { ... } but tasks.withType<...>().configureEach { ... } or all tasks of that type get realized and configured prematurely instead only when needed.

[mbonnin]

Yep, that ☝️ . Thank @Vampire

[Carter]

Thanks—I got that to work and learned something new with the configureEach.

Related, how does one get the output of the build to target older JVM versions while building with newer JVM versions?

I currently get this build warning if I use toolchains.

'compileJava' task (current target is 17) and 'compileKotlinJvm' task (current target is 11) jvm target compatibility should be set to the same Java version.
By default will become an error since Gradle 8.0+! Read more: <https://kotl.in/gradle/jvm/target-validation>
Consider using JVM toolchain: <https://kotl.in/gradle/jvm/toolchain>

[Vampire]

Did you have a look at those links?

[mbonnin]

Use a toolchain 🤓

[Carter]

Yes but means dropping to a Java 11 toolchain to generate Java 11 output, right?

[mbonnin]

You can use a Java19 toolchain and set the target to 11

[Carter]

But then you get the warning I just mentioned above.

[Carter]

So I’m trying to figure out how to use a newer toolchain but emit class files compatible with older JVMs.

[Vampire]

The question is why you should do so.
You usually set a toolchain and not configure a target version.
That's why you set a toolchain. It uses that toolchain and produces bytecode for that toolchain.

[Vampire]

Why do you want to use a newer toolchain but configure an older target?

[mbonnin]

It makes sense to use latest toolchain (for faster GC for an example) but still set target version (for compatibility with older runtimes)

[Carter]

What Martin says, but also there’s a historical example.

[mbonnin]

We do something like this

project.tasks.withType(JavaCompile::class.java).configureEach {
    options.release.set(11)
  }

[Carter]

Historical example: Last year, it was very problematic because there weren’t Apple Silicon compatible toolchains for Java 11 but there were for Java 17.

[Carter]

But to run on a hosted server platform, our output needed to run on Java 11.

[Vampire]

Hm, I see.
Then probably what Martin said. 🙂

[Carter]

Thank you both 🙂

[ephemient]

there's a kotlin extension which can be used instead of configuring the tasks.
for org.jetbrains.kotlin.jvm plugin,

kotlin.target.compilations.all {
    kotlinOptions.jvmOptions = "11"
}

for org.jetbrains.kotlin.multiplatform plugin,

kotlin.targets.all {
    compilations.all {
        (kotlinOptions as? KotlinJvmOptions)?.jvmOptions = "11"
    }
}

[Carter]

I think that’s deprecated now, right?

[ephemient]

but also setting the Java toolchain will set Kotlin's JVM target by default

[ephemient]

as far as I know, only freeCompilerArgs is being deprecated

[tapchicoma]

Last year, it was very problematic because there weren’t Apple Silicon compatible toolchains for Java 11 but there were for Java 17.

SDKMAN should provide such toolchains for Mac silicon and then Gradle will auto detect them.

With Gradle 7.6 probably this plugin will auto-provision toolchains for Apple silicon.

[ephemient]

https://youtrack.jetbrains.com/issue/KT-15370/Gradle-DSL-add-module-level-kotlin-options seems relevant

[Carter]

The Apple Silicon problem is partially solved now, as adoptium has a java 11 JDK now and Gradle should fetch that. So its fine as long as no one needs to target Java 8 😬