I just realized, much to my surprise, that in some...

# k2-adopters

[Olaf Gottschalk]

I just realized, much to my surprise, that in some projects where I still deliberately use Kotlin 1.9.25, the Kotlin standard library was bumped to 2.0.21 due to some transitive dependencies of libraries I updated. I did not realize this before and it's already like this in production... without problems.

Is there an inherent risk in using the Kotlin 1.9.25 compiler / toolchain and the Kotlin standard lib already on 2.0.21?

Why did I notice just now? I wanted to update one of my libs again to their latest version and because those now went to Kotlin 2.1.+, this breaks because there is a binary incompatibility introduced between Kotlin 2.0 and Kotlin 2.1... :(

[mbonnin]

On the JVM this is fine. On other platforms, you would have got a build error because the 1.9 compiler cannot read the kotlin-stdlib:2.0 metadata.

[mbonnin]

this breaks because there is a binary incompatibility introduced between Kotlin 2.0 and Kotlin 2.1

Can you detail your error? kotlin-stdlib has never had a binary breaking change to my knowledge

[Olaf Gottschalk]

I get compile errors that state that Kotlin.Unit does not match...

[mbonnin]

This is... weird. If you share your error we could investigate more but 2.1 should be able to compile against 2.0 libs without issues

[semoro]

Kotlin Compiler of version 1.9.25 can't read metadata of libraries compiled with 2.1 and that’s expected. Metadata format is forward compatible to one version ahead.

Stdlib doesn’t have any binary breaking changes except experimental things. That means that you can use stdlib 2.1 at runtime

[Olaf Gottschalk]

@semoro Thanks, this explains everything, I guess! 😉 I now am really curious: the main reason for me being hesitating to update to Kotlin 2.x and staying on Kotlin 1.9.25 was that some features I desperately need are being discontinued. Context Receivers is the main big thing. As long as Context Parameters are not yet available at all, I cannot go forward. I need at least one version that allows experimental CP before I can rework all CR usages. The other are really dangerous sounding WARNINGS about suppression I also desperately need which are yelling at me to not use them in Kotlin 2.x... 😞 I have opened tickets in YT, but I cannot see any progress here. The main thing here is the use of infix functions with more than one argument (of course, the second argument with default value). This is mainly needed due to limitations of running on the JVM where I need to give JvmName to different overloads for generic return types - but that's not possible in interfaces... sigh

[ephemient]

That means you can use stdlib 2.1 at runtime

although if you somehow use kotlin-reflect:1.9, it may fail to read newer metadata

[kirillrakhman]

@Olaf Gottschalk we expect to land context parameters as beta in 2.2. However context receivers continue working in 2.0 and 2.1. They will eventually be removed in 2.3 or later, though.

The error suppression warnings shouldn't stop you from upgrading unless you use -werror. If you do, we can provide a compiler argument to disable the warning for now. Of course we guarantee no compatibility but we won't break things on purpose.

[Olaf Gottschalk]

@kirillrakhman thanks for giving that insight! Do you know how I can silence the warnings about my suppression of "INAPPLICABLE_INFIX_MODIFIER"? The IDE offers another suppression of "ERROR_SUPPRESSION" - but that does not work...

[kirillrakhman]

Use the compiler argument -Xdont-warn-on-error-suppression it's experimental, therefore we also don't guarantee any compatibility (you know I have to say that :P).

[Jilles van Gurp]

Kotlin does not really do LTS releases currently so 1.9 is kind of getting old news at this point. At this point, it's probably easier to just start planning to upgrade.

Kotlin 2.0 on purpose kept language compatibility with 1.9 to make upgrading easy even though they did replace the compiler. But that's not going to stay true. 2.1 has a few language changes and we can expect more with 2.2 and beyond.

The library ecosystem is not going to slow down and things like co-routines, which are heavily used in many kotlin libraries tend to not preserve backwards compatibility for too long. So, if any of your dependencies moves to a newer version, you are kind of forced to upgrade. As time moves forward. There will be less and less stuff you can add as a dependency without risking major things breaking because of transitive dependencies. It's easiest to just stay on top of things.

I use the refreshVersions plugin which makes it easy to control versions of what you use. My strategy is to update regularly and not get stuck depending on outdated stuff. If I can't upgrade something, I'll do work to resolve it or remove it; I don't allow that to block progress. Makes life easier and I get all the latest fixes, features, and performance work.

As for context receivers and other experimental features, I'm glad I did not start using that. I was tempted to but it was labeled experimental for a reason probably. If you use any experimental stuff you really should stay on top of updates of course.

[Olaf Gottschalk]

@Jilles van Gurp I am totally the same, always keeping things up to date and from day 1 of Kotlin 2 I got my updated branch, so good to go. What I didn't expect are sudden serious sounding warnings about suppress things to be not supported anymore (which I heavily rely on) and the annoying warnings for Context Receivers (which I heavily rely on, too). So, it just did not "feel" right to go Kotlin 2 productively yet. But as time goes by and now I see the problems piling up, I will probably go for the latest. I would be more confident though if my YT issues had more traction... :-(

[Olaf Gottschalk]

I.e. the noisy warning that Context Receivers will be removed. One warning at the place where I enable the experimental feature in my build file would be enough, I think. No point in throwing hundreds of warnings at me... 😉