This message was deleted.

My use case is that

kotlin-dsl

is using

org.jetbrains.kotlin:kotlin-sam-with-receiver

with the version

1.7.10

, so it is not building due being incompatible with the new update of Kotlin

1.7.20

kotlin-dsl

is also incompatible with

1.7.10

as it uses an older version. And, no, it's not possible, because it needs to be resolved and included in the plugins classpath. It's like using Groovy 4 in Groovy 3, or Java 18 in Java 8.

for me it is compatible

Gradle currently ships with Kotlin

1.6.21

, that is

2.3.3

of the

kotlin-dsl

. Including

3.1.0

in your dependencies is not changing that, it just leads to more incompatibility whenever your plugin is included in any Gradle build. Until a new Gradle version is released with the updated

kotlin-dsl

that is.

Then I think the correct approach is dropping Kotlin DSL and use the java gradle plugin to avoid those incompatibilities

Indeed it is, or to use the correct versions, which is actually simple since Gradle provides variables to get them:

build.gradle.kts

println(org.gradle.kotlin.dsl.embeddedKotlinVersion)
println(org.gradle.kotlin.dsl.support.expectedKotlinDslPluginsVersion)

The caveat is that the plugin you build is now tied to Gradle releases that contain a compatible Kotlin version. This can get hairy very quickly, since Kotlin evolves extremely fast and does not have the stability of Java: https://kotlinlang.org/docs/kotlin-evolution.html That said, if you are willing to simply always require latest of everything, and update your things in a timely manner than you can easily build Kotlin libraries and plugins that are Gradle compatible.

gradle-compatible-kotlin-library/build.gradle.kts

plugins {
  kotlin("jvm") version embeddedKotlinVersion
}

gradle-compatible-kotlin-plugin/build.gradle.kts

plugins {
  `kotlin-dsl`
}

gradle-compatible-plugin-that-applies-the-kotlin-dsl/build.gradle.kts

import org.gradle.kotlin.dsl.support.expectedKotlinDslPluginsVersion

plugins {
  `kotlin-dsl`
}

dependencies {
  api("org.gradle.kotlin:gradle-kotlin-dsl-plugins:$expectedKotlinDslPluginsVersion")
}

Thank you for your detailed answer 🙂

You're welcome. 😊

I think I can't because I am using some libraries and plugins that are using Java 11 (JGit, Spotless...) 😞

That's fine, the incompatibility only has to do with Kotlin generated bytecode for the Gradle plugin itself, not any libraries or anything else. The thing is that Gradle compiles all

kts

scripts (e.g.

build.gradle.kts

,

settings.gradle.kts

) with

jvmTarget = 8

and if a plugin is compiled with e.g.

jvmTarget = 11

certain Kotlin features start to fail since they cannot be compiled. Most prominent (and maybe even the only feature 🤷 ) is

inline

. The error message you get is

cannot inline bytecode 11 into 8

(or similar). You can still use dependencies and libraries that target greater Java versions, given that all users of your plugin know that they have to run the Gradle build with a newer Java version.

I have curious about why the community is still stick to Java 8 and not moving forward to Java 11

Why not Java 19? The biggest problem are enterprises who are super cautious about upgrading anything, and Java is all about enterprise.

Because Java 19 was released "yesterday". Java 11 has a lot of years. If a company is not trying to update its Java version which is core, why they are worried about not being able to use newer versions of a plugin that is working for them on an old version?

I know that Java 19 was released yesterday, what I meant to say by it is why we all are not moving a little faster than just 11. LTS is hoax unless one is willing to pay a fortune to Oracle, so 18 would be the realistic target for the entire community to be at, and 19 is what we would be upgrading to right now. The situation with Gradle is actually even more interesting. Gradle could easily move to 18 as a min. requirement. Simply because the toolchain required for compiling the code in question is totally decoupled from the Java that is used to run Gradle itself. It's no problem to use Java 18 for Gradle and compile, build, and test a Java 8 library.

tbh, I try to use all latest versions, but I don't work in a larger company with a large legacy application, what I am sure is I am using Java 18 in all my machines and I am going to move to 19 asap (it has improved build times based on some comments). But in all projects I have participated, the Kotlin last version adoption was delayed less than 1 month as maximum time for example. I said Java 11 to be reasonable with legacy apps, for me it would be fine to have a newer one as a personal approach (something I am already doing with Kotlin, if renovate's PR is green, it is merged).

I do work at a big company and the only thing holding us back from upgrading quickly is that the individual teams are not maintaining their projects properly. Automatic upgrades don't help here if their tests fail, since then it cannot be merged. Hence, one is stuck with supporting older versions. 😞

The problem is exponential, fixing the PR when it appears can be easy, if you wait multiple major versions... GL. I had to migrate a Flutter app which wasn't updating any library. Some major versions were updated and even the migration guides were already deleted from their repositories and I had to find them in the commit histories. Being lazy updating is going to be worse in the future, wasting a few minutes or even seconds can help to avoid wasting days or weeks in the future.

Thank you, it's what I keep telling people, but alas.