Quarkus: Kotlin Coroutines in Quarkus

[akoufa]

Description

Hello to all. I am lately heavily using Quarkus together with Kotlin and I would like to ask you what the progress is, if any, regarding Kotlin Coroutines support in Quarkus APIs. Providing suspendable function APIs, like for example my other feature request, will improve the Quarkus experience for Kotlin developers. Together with the upcoming Hibernate Reactive this would allow us write synchronous-like non blocking code end to end. As Quarkus is based on Vert.x which already has superb Kotlin Coroutines support that is the way to go for Quarkus Kotlin developers. Also Kotlin Coroutines are a compile time construct which do not hinder adopting Project Loom in the future.

Nevertheless I was following the issues in GraalVM Repository and I think the blockers regarding native mode support should be fixed now: https://github.com/oracle/graal/issues/366 https://github.com/oracle/graal/issues/1330 .

[geoand]

cc @evanchooly

[evanchooly]

We're working on a formal timeline but unofficially here's my short term plan:

1. Finish the panache support (currently wrapping up the mongodb-panache support to mirror the JPA support).
2. Make sure dev mode works properly for kotlin projects (there's a couple of issues on this and one PR underway that might clear them all up at once)
3. It's not set in stone yet, but the kotlinx serialization was likely the next target.

As for coroutines in native mode, it's hard to tag that with a specific timeline because the interactions with graalvm make that one hard to gauge. It's likely that one will run in parallel with other tasks until we can crack that code. But I haven't yet dug in to it so it's all speculative at this point.

The hope is to have some meetings this week. There's an issue to track the official roadmap if you want to follow along: https://github.com/quarkusio/quarkus/issues/8194

[evanchooly]

Also, my unordered, unprioritized working list: https://github.com/quarkusio/quarkus/labels/area%2Fkotlin

[emmanuelbernard]

@cescoffier can you CC Arthur so he can put some progress as he finds stuff on the native image compilation for Kotlin co-routines

[emmanuelbernard]

Does it make any conceptual sense that Vert.x has a Kotlin API generator, and whether we should extend this for Quarkus @cescoffier

[cescoffier]

@Tas-Hur <-- That should be Arthur

[Tas-Hur]

Hi, I checked out the fix that allows the compiler to solve issues with irreducible loops : https://github.com/oracle/graal/commit/4662877b8ce214528f09553f21776ab97e97c1a8
It is actually quite simple, to avoid multiple entry points in a loop only one entry point is kept and the other ones are replaced with a copy of the code contained inside the loop. However the compiler has a policy about the number of duplications it allows.

I am currently running some tests to have a better idea of how nesting loops and calling functions with several points of suspension influences the number of duplication. For now I have this basic scenario showing a linear relation between the maximum number of suspending calls and the value of MaxDuplicationFactor :

MaxDuplicationFactor = 1
compiles up to 5 suspending calls in a loop

MaxDuplicationFactor = 2
compiles up to 10 suspending calls in a loop

MaxDuplicationFactor = 3
compiles up to 15 suspending calls in a loop

...

MaxDuplicationFactor = 10
compiles up to 50 suspending calls in a loop

[rainmanhhh]

webflux works with suspend fun now. maybe you can refer to it?

[akoufa]

Hello to all. Any updates on supporting Kotlin Coroutines ?

[BloodShura]

The absence of support for Kotlin coroutines is really the only thing keeping my team from using Quarkus right now. Guess we gotta stick with Spring+WebFlux for a while...

[cescoffier]

I believe Kotlin co-routines are supported in JVM mode. I don't see why they should not. Also, with the recent GraalVM changes, it may work in native (but I would be a bit more careful about that).

Ping @evanchooly

[evanchooly]

Yeah, coroutines should absolutely work in JVM mode. There were some significant hurdles the last time someone looked at native mode but I haven't had a chance just yet. It's on the list to revisit soon, though. Hopefully JetBrains and the graalvm team have worked out some of the issues.

[evanchooly]

now dev mode might be another issue but I think that's literally the next item on my list to tackle.

[akoufa]

@evanchooly @cescoffier Kotlin Coroutines can be used in Quarkus JVM mode but If I am not mistaken there are some heavy limitations. For example:

It is not possible to define suspend Jax-RS Routes. Currently a workaround has to be used to convert from a coroutine to Jax-RS Mutiny. Also Quarkus does not provide any executors needed to run Kotlin Coroutines. Again we have to use the ones from Infrastructure.getDefaultExecutor() of Mutiny or some other workaround. What about context propagation ?

Quarkus performance could be improved if threading could be controlled by the application code using Kotlin Coroutines fine grained mechanisms. Starting from a suspend Jax-RS endpoint which runs on the IO Pool and then if needed with the Kotlin Coroutines construct withContext to change to the Worker Pool, for example when calling a blocking API like Hibernate or not when using Hibernate Reactive or some other non blocking API.

I think it would a huge improvement in Quarkus Kotlin experience if it would be possible to address these issues considering that these features are already available in Spring Boot or Micronaut.

Nevertheless I have to thank you for your work so far in supporting Kotlin in Quarkus.

[sherl0cks]

Yeah, coroutines should absolutely work in JVM mode. There were some significant hurdles the last time someone looked at native mode but I haven't had a chance just yet. It's on the list to revisit soon, though. Hopefully JetBrains and the graalvm team have worked out some of the issues.

Came across this issue. Be advised of https://medium.com/graalvm/graalvm-20-1-7ce7e89f066b. Works great in my testing so far. Had significant issues pre graal 20.1