:loudspeaker: <https://jb.gg/06i60h|KOTLIN ROADMAP...

# announcements

[Ksenia Shneyveys]

📢 KOTLIN ROADMAP UPDATE: Get ready for the upcoming improvements!

Kotlin 2.0 with a Stable K2 Compiler is on the horizon!
The K2 compiler aims to bring major performance improvements, speed up new language feature development, and provide a better architecture for multiplatform projects. It will go stable in Kotlin 2.0. In the run-up to this, we will address user feedback from the K2 Beta release, support Kotlin Scripting with K2, and release the first version of the K2-based IntelliJ plugin.

Kotlin Multiplatform to Go Stable This Year!
The Kotlin team at JetBrains is continuing to stabilize Kotlin Multiplatform. We’ve already deprecated outdated pieces of the Multiplatform toolchain, introduced levels of stability into the Kotlin/Native standard library, and updated the API to enable Google to create their own plugin for multiplatform project support for Android targets.

The stable Kotlin Multiplatform will also bring improved Kotlin/Native interoperability with iOS, a more performant Kotlin/Native memory manager, improved Kotlin/Native compilation time, full support for Kotlin Multiplatform in K2, and a more user-friendly and comprehensive onboarding experience for new users.

More great stuff to boost your productivity with Kotlin:
• We plan to promote Kotlin/Wasm to Alpha. As part of this, all official versions of JetBrains libraries (including all kotlinx libraries, Ktor and Compose Multiplatform) will gain support for the Kotlin/Wasm target!
• We are also working to make Kotlin/Wasm suitable for standalone Wasm VMs (without JavaScript support).
• We are developing the new foundational library, kotlinx-io, which is based on the Okio foundation and leverages its top-notch, battle-tested design and implementations.
• We aim to improve the Android debugging experience and make it easier to debug inline classes and inline functions.
For the full picture, head over to our detailed Roadmap page. Discover our achievements, understand our primary goals and plans, and, as always, we’d love to hear your feedback!

[Joel Denke]

Out of curiosity, has Apple in any way expressed similar wishes as Google build their plugin? Would be amazing if they joined KMP in some way.
I am so excited about 2.0 release and all improvements. Amazing work everyone! 👌🎉

[Loïc Lamarque]

Kotlin 2.0 is gonna be amazing! 🦜
Thank you all for your work on this language! 🔥

[Edoardo Luppi]

@Joel Denke Apple likes keeping its ecosystem closed. There is a reason building tools that work alongside Xcode is a PITA

[John Matthews]

Xcode is part of the Pacific International TrapShooting Association! lol

[윤동환]

what is the jvm target version of kotlin 2.0?

[Zach Klippenstein (he/him) [MOD]]

i’m super excited for kotlinx-io – having a rock-solid, foundational IO library is gonna make so many cool use cases easier to support in kmp

[Norbi]

kotlinx-io

@Ksenia Shneyveys, why choose an API as the base of the new library where I/O operations are not suspend ? 🤔

[Stephan Schröder]

@윤동환 the jvm target of Kotlin is configurable. Since Kotlin 2.0 comes out months after Java21, I expect JVM21 to be a target option.

[윤동환]

@Stephan Schröder thanks for your answer. Then using Kotlin 2.0 with JDK1.8 is not possible. im sad

[Stephan Schröder]

@윤동환 I didn't say anything about JDK1.8, I assumed you were curious over JDK21. As far as I know JDK1.6 got deprecated (or even removed), but JDK1.8 is still a valid target. I've heard nothing that that version was about to be retiered. Isn't that the Version that Android now uses?? In which case the existence of a JDK1.8 target would be super secure.

[Joel Denke]

If I recall, Android is forced using JDK11 as of AGP 8 but uncertain. Not forced using latest versions. Its more about Android Studio and IntelliJ not Android itself. Most apps using 11 or 17 today I think.

[Zach Klippenstein (he/him) [MOD]]

kotlinx-io

@Ksenia Shneyveys, why choose an API as the base of the new library where I/O operations are not suspend ? 🤔

@jessewilson can answer this better than me, but I believe that the overhead of coroutines was unacceptable for low-level io operations.

[jessewilson]

Here’s a discussion:
https://github.com/square/okio/issues/814

[jessewilson]

I claim:
• suspend function calls are fast
• non-suspending function calls are very fast
• I/O libraries like JSON parsers, protobuf encoders, HTTP processors etc. are quite sensitive to the cost of making function calls
• Doing one withContext(<http://Dispatchers.IO|Dispatchers.IO>) and then doing a bunch of blocking calls is likely to be meaningfully faster than doing many suspending calls
Retrofit’s suspend feature works this way. I think both its API and its performance are great. Doing a suspend call for every byte processed would harm performance without improving the developer experience.

[Norbi]

Thanks for the detailed info.

likely to be meaningfully faster

Although in this case I have a feeling that performance is prioritized over "correctness". @elizarov said multiple times how important it is to differentiate between suspend and non-suspend functions for code "correctness".
Besides, if suspend functions are dropped for performance reasons, then it is a very bad message for ktor users...
(I don't want to seem very clever, I was just very surprised by this decision. And I know that this thread is not the best place for this discussion, too 🙂 )

[Joffrey]

@Norbi an HTTP call which writes the whole request + reads the whole response is a much higher-level operation than reading one byte of data from a source. Suspending on every byte read from a source doesn't have the same consequences as suspending on each HTTP call as a whole. So I don't think that this approach questions Ktor's approach.

Also, as far as I'm aware, the Kotlin team intends to provide a suspending way to wait for a number of bytes to be "ready" so that a blocking read would not actually block. So we will still get out-of-the-box integration with coroutines AFAIU.