# Kotlin Coroutines and (upcoming) Java Loom **URL:** \ **Category:** Language Design\ **Created:** [January 10, 2020, 11:45am UTC](https://discuss.kotlinlang.org/t/kotlin-coroutines-and-upcoming-java-loom/15819 "2020-01-10T11:45:46Z")\ **Posts on this page:** 2\ **Page:** 3
**Author:** ![mnhattt](https://avatars.discourse-cdn.com/v4/letter/m/e0b2c6/32.png) [@mnhattt](https://discuss.kotlinlang.org/u/mnhattt)\ **Post date:** [January 30, 2023, 7:51am UTC](https://discuss.kotlinlang.org/t/kotlin-coroutines-and-upcoming-java-loom/15819/44 "2023-01-30T07:51:15Z")
My concern is will kotlin gain any advantage from loom in: - performance aspect (don’t change any async model, syntax) - DX aspect (change programming model, languague syntax, etc) - maybe both ---
**Author:** ![mtimmerm](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/mtimmerm/32/7160_2.png) [@mtimmerm](https://discuss.kotlinlang.org/u/mtimmerm)\ **Post date:** [February 3, 2023, 1:20am UTC](https://discuss.kotlinlang.org/t/kotlin-coroutines-and-upcoming-java-loom/15819/45 "2023-02-03T01:20:07Z")
> [@gidds](#): > > Is there likely to be any scope for changing the _implementation_ of coroutines to use Loom? Yes, in the last version of Loom that I looked at, enough of the basic facilities were exposed that it would be possible to use them to implement Kotlin coroutines, providing a significant performance improvement. Some of those APIs, though, were undocumented and not intended for public use at that time. If the Java developers really do not want Kotin coroutines and similar things to be possible with the Loom machinery, then they could prevent it without impacting Java functionality. The public virtual thread interfaces that Java Loom provides are not quite enough to do the job. [Previous page](https://discuss.kotlinlang.org/t/kotlin-coroutines-and-upcoming-java-loom/15819.md?page=2)