Bump to Kotlin 1.4

[jamesward]

Kotlin 1.4 is out. But if we switch, is it backwards compatible to 1.3?

[chalin]

Does this mean that 1.4 is the new minimum supported version? Cf. https://grpc.io/docs/languages/kotlin/quickstart/#prerequisites

[chalin]

@bshaffer - any comment about this?

[jamesward]

I don't think we should bump it if that means we require 1.4 - but I'm not sure if that'd be the case. We need to do more research on Kotlin & backwards compatibility stuff.

[chalin]

We need to do more research on Kotlin & backwards compatibility stuff.

Ok. Thanks for keep me posted.

[asarkar]

Most other Kotlin libraries have upgraded to 1.4, and using the latest of those with grpc-kotlin creates conflicts. I don't think it matters for the client what Kotlin version a library uses (unless, of course, conflicts exist as mentioned before). I have a library that's built on Kotlin 1.4 but used by Java 8 client, and they don't have any problems.

Besides, grpc-kotlin is not even GA yet, there shouldn't be any expectations of backward compatibility by any client.

[jamesward]

@asarkar What are the conflicts?

[asarkar]

@jamesward NoSuchMethodError, telltale sign of incompatible versions on the classpath. Usually, I was able to exclude the transitive dependencies and get it working, but it’s clunky (bunch of excludes), but if they depended on a 1.4 only feature, I used an older version.

[jamesward]

It seems there is some tricky things around Kotlin library compatibility. Today I tried to upgrade a Kotlin 1.3 project to coroutines 1.3.9 (which supports 1.4) and got errors. The Scala ecosystem appends the major version to the artifact, like foo_2.13 and library authors publish artifacts for each major version they support. It's a pain, but I wonder if Kotlin will have to start doing the same thing.

[asarkar]

@jamesward just checking on this. Recently, I was able to use a library compiled with Kotlin 1.4 and targeted for Java 8 in a Kotlin 1.3 client by excluding the Kotlin libs, like so:

testImplementation("com.asarkar.spring:embedded-redis-spring:$embeddedRedisSpringVersion") {
    exclude("org.jetbrains.kotlin")
}

[jamesward]

So far I've been ok using these with Kotlin 1.4.10:

io.grpc:grpc-kotlin-stub:0.2.1
org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.9

I think the trick is to use 1.3.9 instead of 1.3.8. If that is causing errors then we probably need to get a reproducible project.

[asarkar]

I'm little confused, are you saying there's a version of grpc-kotlin that targets Kotlin 1.4.x? I'm looking at the release notes, and I'm not seeing anything to that effect. Or perhaps you're saying that grpc-kotlin built with Kotlin 1.3 would work with a client project targeted for Kotlin 1.4? That produces a warning about two different Kotlin stdlib present on the classpath, and a threat of unknown errors at runtime. Something like the following:

w: Runtime JAR files in the classpath should have the same version. These files were found in the classpath:
    C:/Users/usr/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-reflect/1.2.71/7512db3b3182753bd2e48ce8d345abbadc40fe6b/kotlin-reflect-1.2.71.jar (version 1.2)
    C:/Users/usr/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib/1.2.71/d9717625bb3c731561251f8dd2c67a1011d6764c/kotlin-stdlib-1.2.71.jar (version 1.2)
    C:/Users/usr/.gradle/caches/modules-2/files-2.1/org.jetbrains.kotlin/kotlin-stdlib-common/1.3.41/2ecf4aa059427d7186312fd1736afedf7972e7f7/kotlin-stdlib-common-1.3.41.jar (version 1.3)
w: Consider providing an explicit dependency on kotlin-reflect 1.3 to prevent strange errors
w: Some runtime JAR files in the classpath have an incompatible version. Consider removing them from the classpath or use '-Xskip-runtime-version-check' to suppress this warning

The versions in the error message are representative, the point being version conflict.

use 1.3.9 instead of 1.3.8

The latest kotlinx-coroutines-core version is 1.4.1.

[jamesward]

You should be able to use grpc-kotlin 0.2.1 with Kotlin 1.3 & 1.4. I think that the warning you are seeing can be fixed by adding an explicit dependency on kotlin-reflect (with whatever 1.4 version you are using). If you have issues with that approach I might need a small project that reproduces this.

[jeffzoch]

Maybe we can change this to kotlin 1.5 (really 1.6 is coming soon so maybe even that)?