grpc-kotlin
grpc-kotlin copied to clipboard
grpc
Bump to Kotlin 1.4
Kotlin 1.4 is out. But if we switch, is it backwards compatible to 1.3?
Does this mean that 1.4 is the new minimum supported version? Cf. https://grpc.io/docs/languages/kotlin/quickstart/#prerequisites
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.
We need to do more research on Kotlin & backwards compatibility stuff.
Ok. Thanks for keep me posted.
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 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.
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.
@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")
}
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.
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.
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.
Maybe we can change this to kotlin 1.5 (really 1.6 is coming soon so maybe even that)?
