Could Virtual Threads cast away the usage of Kotlin Coroutines - DevoxxUK2025

This is an updated version of the original presentation I did at the LJC in 2024 at the Couchbase offices. This version, tailored for DevoxxUK 2025, explores all of what the original one did, with some extras. How do Virtual Threads can potentially affect the development of resilient services? If you are implementing services in the JVM, odds are that you are using the Spring Framework. As the development of possibilities for the JVM continues, Spring is constantly evolving with it. This presentation was created to spark that discussion and makes us reflect about out available options so that we can do our best to make the best decisions going forward. As an extra, this presentation talks about connecting to databases with JPA or JDBC, what exactly plays in when working with Java Virtual Threads and where they are still limited, what happens with reactive services when using WebFlux alone or in combination with Java Virtual Threads and finally a quick run through Thread Pinning and why it might be irrelevant for the JDK24.

Transcript

1. Could Virtual Threads cast away the usage of Kotlin Coroutines? What experience can tell us… How coroutines have changed the JVM programming world and how Java Virtual Threads can change that? By João Esperancinha 2025/05/09
2. Who am I? João is a 10+ years experienced Software Developer, Studied Telecom Engineering at ISEL Lisboa, and worked in different companies in Portugal, Spain, and The Netherlands. He is a certified Kong Champion, a certified Java Developer (OCP11) and is a Certified Spring Professional 2021. Outside the software development Universe, João is someone interested in arts and crafts and making stuff out of old materials creating the occasional modified furniture. João loves plants and has a small potted garden with Yuccas and blueberry bushes. He has one particular YouTube channel called JESPROTECH dedicated to engineering where João shares his experience with the world.
3. Quick Threads History 1995 - Java 1.0 and Green Threads 1998 - Java 1.2 and Transition to Native Threads 2004 - Java 5 (1.5) and Concurrency Utilities 2011 - Kotlin Language Announced 2014 - Project Loom Announced 2017 - Kotlin 1.1 and Introduction of Coroutines 2019 - Project Loom Early Access Builds 2022 - Java 19 and Preview of Virtual Threads 2023 - Java 21 and Official Release of Virtual Threads 2024 - Java 23 - 17th September - Less Pinning, but not significant 2025 - Java 24 - 18th March 2025 with JEP 491
4. Fetch all data diagram (Horrendous old way to fetch data for Server Side, but great for mobile … sometimes) Fetching data
5. Structured Concurrency using Virtual Threads try (var scope = new StructuredTaskScope.ShutdownOnFailure()) { var userDeferred = scope.fork(() -> fetchUser(userId)); var postsDeferred = scope.fork(() -> fetchUserPosts(userId)); var commentsDeferred = scope.fork(() -> fetchUserComments(userId)); scope.join(); scope.throwIfFailed(); var processedData = processUserData( userDeferred.get(), postsDeferred.get(), commentsDeferred.get()); updateUI(processedData); logger.info(() -> "Complete!"); } catch (ExecutionException e) { throw new RuntimeException(e); } catch (InterruptedException e) { throw new RuntimeException(e); } Fetching data with Java Virtual Threads (Java) Highly verbose! This is blocking! Alternative: Thread.startVirtualThread ?
6. Structured Concurrency using Virtual Threads Fetching data with Java Virtual Threads (Kotlin) ShutdownOnFailure().use { scope -> val userDeferred = scope.fork { fetchUser(userId) } val postsDeferred = scope.fork { fetchUserPosts(userId) } val commentsDeferred = scope.fork { fetchUserComments( userId ) } scope.join() scope.throwIfFailed() val processedData = processUserData( userDeferred.get(), postsDeferred.get(), commentsDeferred.get() ) updateSytem(processedData) logger.info("Complete!") } Still blocking! Alternative: Thread.startVirtualThread ? Still Highly verbose!
7. Structured Concurrency using Kotlin Coroutines CoroutineScope(IO).launch { val userDeferred = async { fetchUser(userId) } val postsDeferred = async { fetchUserPosts(userId) } val commentsDeferred = async { fetchUserComments(userId) } val user = userDeferred.await() val posts = postsDeferred.await() val comments = commentsDeferred.await() val processedData = processUserData(user, posts, comments) updateSytem(processedData) logger.info("Complete!") } Fetching data Is this not verbose? 🤔 It is better! 😀 Not blocking! 😀
8. Sending messages Send messages diagram (N user messages, packed in 50 messages sent in parallel - Fire and forget)
9. Fire and Forget with Kotlin Coroutines suspend fun sendMessage(text: String, users: List<User>) = coroutineScope { users.chunked(50).map { it.map { async { retry(5, 500) { sendEmail(text, it) } } }.awaitAll() } } Sending Messages Needs a coroutine scope!
10. Fire and Forget with Java Virtual Threads fun sendMessage(text: String, users: List<User>) = users.chunked(50).map { it.map { startVirtualThread { retry(5, 500) { sendEmail(text, it) } } }.forEach { it.join() } } Sending Messages No need for a coroutine scope… but now we wait?🤔 Now it is just a choice! 😀 Example: Thread.startVirtualThread
11. Making tests Using docker-compose 1. fulfilment: 2. hostname: mvc 3. build: 4. context: . 5. ports: 6. - "8080:8080" 7. expose: 8. - 8080 9. deploy: 10. resources: 11. limits: 12. cpus: 4.0 13. memory: 1G locust -f locust_fulfilment.py --host=http://localhost:8080 Take a part of the machine
12. Making tests Using docker-compose 1. postgres: 2. hostname: postgres 3. build: 4. context: ../docker-psql/. 5. env_file: ../docker-psql/.env 6. user: postgres 7. volumes: 8. - ../docker-psql:/docker-entrypoint-ini tdb.d 9. healthcheck: 10. test: [ "CMD", "pg_isready", "-U", "postgres" ] 11. interval: 10s 12. timeout: 5s 13. retries: 5 locust -f locust_fulfilment.py --host=http://localhost:8080
13. Making tests Using docker-compose 1. CREATE EXTENSION IF NOT EXISTS "uuid-ossp"; 2. 3. 4. CREATE TABLE product 5. ( 6. id UUID DEFAULT uuid_generate_v4() PRIMARY KEY, 7. name VARCHAR(255) NOT NULL, 8. isle_type VARCHAR(255) NOT NULL 9. ); 10. 11. DO $$ 12. BEGIN 13. FOR i IN 1..1000 LOOP 14. INSERT INTO product (id, name, isle_type) 15. VALUES (gen_random_uuid(), 'Sample Product ' || i, 'Room'); 16. END LOOP; 17. END $$; 18. locust -f locust_fulfilment.py --host=http://localhost:8080
14. Python code to make tests Python code called by locust to perform tests from locust import HttpUser, TaskSet, task, between class UserBehavior(TaskSet): @task def get_fulfilment(self): url = "/api/v1/fulfilment" params = {} headers = {"Accept": "application/json"} with self.client.get(url, params=params, headers=headers, catch_response=True) as response: if response.status_code == 200: response.success() print(f"Status Code: {response.status_code}, Response: {response.text[:100]}") else: response.failure(f"Failed with status code: {response.status_code}") class WebsiteUser(HttpUser): tasks = [UserBehavior] wait_time = between(1, 3) def on_start(self): pass def on_stop(self): pass URL + Headers
15. Traditional Spring MVC @RestController @RequestMapping("fulfilment") class FulfilmentController { @GetMapping fun getItems(): List<Product> = productService.getAllItems() @GetMapping("{id}") fun getItem(@PathVariable id: UUID): Product? = productService.getItemById(id) companion object { val logger: Logger = LoggerFactory.getLogger(FulfilmentController::class.java) } } This was the old way. Or is it? 🤔
16. Web MVC - Locust test - Max 100000 users ; Spawn Rate 1000 users/seconds
17. Web MVC - Locust test - Max 100000 users ; Spawn Rate 1000 users/second
18. Traditional Spring MVC Great pattern, but not that capable. Not “fast” enough. • Easy pattern to learn • Good 3 tier model • Model, View, Controller • Domain model • Data transfer object • Converters Problem? • Not many were aware of the inefficient aspect of it • The inefficiency only appeared when raising the load Why was there a need to improve it? • The idea was there all along • When comparing the performance of Spring for higher loads, Spring and other JVM based solutions would fail to be on top. June 2003
19. Reactive Services in Spring MVC - WebFlux @RestController @RequestMapping("fulfilment") class FulfilmentController { @GetMapping fun getItems(): Flux<Product> = productService.getAllItems() @GetMapping("{id}") fun getItem(@PathVariable id: UUID): Mono<Product> = productService.getItemById(id) companion object { val logger: Logger = LoggerFactory.getLogger(FulfilmentController::class.java) } } Flux starts reactive revolution, but how good was/is it?
20. WebFlux - Locust test - Max 100000 users ; Spawn Rate 1000 users/second
21. WebFlux - Locust test - Max 100000 users ; Spawn Rate 1000 users/second
22. Reactive Programming • Blockhound • Flux / Mono • Flux were used for collections • Mono used for instances • Good support for R2DBC • Good support for Spring • The Observability pattern and publishers were visible Problem? • Coding would get extremely complicated • Particularly zipping functions Spring WebFlux - 2017 (my sea-shell-archiver became too complicated!)_
23. Reactive Services with Spring Kotlin Coroutines @RestController @RequestMapping("fulfilment") class FulfilmentController { @GetMapping fun getItems(): Flow<Product> = fulfilmentService.getAllItems() @GetMapping("{id}") suspend fun getItem(@PathVariable id: UUID): Product? = fulfilmentService.getItemById(id) companion object { val logger: Logger = LoggerFactory.getLogger(FulfilmentController::class.java) } } A flow is programmed like flux but the backbone is made with Kotlin Coroutines and it works with the assigned dispatcher by Spring
24. Kotlin Coroutines - Locust test - Max 100000 users ; Spawn Rate 1000 users/second
25. Kotlin Coroutines - Locust test - Max 100000 users ; Spawn Rate 1000 users/second
26. Why Kotlin Coroutines? Kotlin’s inception year - 2016 • Scope creation instead of a specific structured concurrency block • Structured concurrency • Non-preemptive scheduling • Cooperative multitasking • Better usage of resources • Concurrency • Additional benefit of parallelism • Dispatchers
27. Kotlin Coroutines • Claimed to be simpler than using Flux and Mono • Instead of Mono we started using suspend • Instead collections, we started using flow • The rise of the usage of Channels, hot flows, cold flows • Talks about removing Kafka, RabbitMQ and major dedicated data stream frameworks Problem? • Coroutine complexity was still considerable when using structured concurrency • Because of the non-preemptive model all functions and its instances would have to be marked as suspend • No simple function could call suspend • Many developers still try to use suspend with a returned list or even with flows. In some cases also with Flux. Compatibility with Spring - 2019
28. Coroutines to Virtual Threads (gross simplification)
29. Virtual Threads in Spring # Server server.port=8080 spring.main.web-application-type=servlet spring.mvc.servlet.path=/api/v1 # Enable Virtual Threads for WebFlux spring.threads.virtual.enabled=true # Thread pool configuration #spring.task.execution.pool.max-size=16 #spring.task.execution.pool.queue-capacity=100 #spring.task.execution.pool.keep-alive=10s We can activate virtual threads We can choose between Blocking (servlet) and Reactive (reactive)
30. Virtual Threads in Spring @RestController @RequestMapping("fulfilment") class FulfilmentController { @GetMapping fun getItems(): List<Product> = productService.getAllItems() @GetMapping("{id}") suspend fun getItem(@PathVariable id: UUID): Product? = productService.getItemById(id) companion object { val logger: Logger = LoggerFactory.getLogger(FulfilmentController::class.java) } } It’s back! And now we are back to the old model!😁
31. Locust test - Max 100000 users ; Spawn Rate 1000 users/second
32. Locust test - Max 100000 users ; Spawn Rate 1000 users/second
33. Virtual Threads • Turns everything on its head for Spring • There is no keyword or special objects needed • The application benefits from non-blocking • The preemptive/non-preemptive (hybrid) scheduling form makes sure that we can virtualize threads in a code that goes back to the imperative form, without the need to be forced to make major decisions • The use of scopes is off the table and not needed Problem? • Structured concurrency support is very verbose • Many frameworks surrounding Kotlin like Project arrow rely on coroutines for their features. • Streams, channels and flows are fully supported by coroutines, while it is still cumbersome to do that in Java • Mobile application development is mostly based on Kotlin and Kotlin Coroutines. Started with Loom as Fibers in 2017 Released in 2023 with the JDK 21
34. Coroutines with Virtual Threads (gross simplification)
35. Coroutines on Virtual Threads in Spring @RestController @RequestMapping("fulfilment") class FulfilmentController { @GetMapping fun getItems(): Flow<String> = (1..10).asFlow().map { val product = Product(name = "TV", isleType = Room) logger.info("Product: $product") product.name }.flowOn( Executors.newVirtualThreadPerTaskExecutor() .asCoroutineDispatcher() ) companion object { val logger: Logger = LoggerFactory.getLogger(FulfilmentController::class.java) } } An odd construction, but does it stand?🤔
36. Locust test - Max 100000 users ; Spawn Rate 1000 users/second
37. WebFlux on Virtual Threads in Spring @RestController @RequestMapping("fulfilment") class FulfilmentController { @GetMapping fun getItems(): Flux<Product> = productService.getAllItems() @GetMapping("{id}") fun getItem(@PathVariable id: UUID): Mono<Product> = productService.getItemById(id) companion object { val logger: Logger = LoggerFactory.getLogger(FulfilmentController::class.java) } } The virtual flag is activated along with reactive
38. WebFlux with Virtual Threads - Locust test - Max 100000 users ; Spawn Rate 1000 users/second
39. Virtual Threads Combined With Kotlin Coroutines • A different perspective on Threads with potential benefits • I never used it in production • Maybe it is not an improvement. • Again, testing is needed and lot of benchmarking is needed in order to make adequate decisions • Garbage Collection issues • Thread Pinning 2023 lot’s of blogs released: I did that too: https://github.com/jesperancinha /good-story
40. Thread Pinning • One virtual thread sticks to one platform thread • Pinning means it CANNOT yield until completion • Mounting means it CAN yield until completion • Platform thread cannot schedule other virtual threads until blocking operation finishes • Non-reactive API’s like JPA and JDBC rely on several blocking paradigms making it difficult to take benefits from using Java Virtual Threads • JDK 24 is designed to eliminate Thread Pinning
41. GitHub - Good Story - Virtual Thread Dispatcher in combination with Kotlin Coroutines
42. Conclusion • Virtual threads are very impactful because of their support by the Spring Framework. They are easy to use and build code with. Maintain that code is easy. It can be used in: ◦ Fire and forget scenarios ◦ Structured concurrency ◦ Both Java and Kotlin • Coroutines will still be used because of how well and elegantly they adapt to other paradigms: ◦ Flows ◦ Channels ◦ Event Streaming ◦ SSE ◦ Can be used in Both Java and Kotlin, but they are not prepared for Java and can get highly complicated that way • In any case, both can be used with similar or purely equal performance markers, leading to choosing them on the bases of code style, patterns and design.
43. Could Virtual Threads cast away the usage of Kotlin Coroutines? No! Kotlin Coroutines still provide a more simplified way of using WebFlux with Flows and suspend functions. Kotlin is still a first class citizen in the world of code style and simplification for the JVM and Coroutines are a perfect match They are simple, we don’t need complicated code and we don’t even need to think about Dispatchers Yes! • Kotlin Coroutines are still a simplified alternative to Mono/Flux ❌ • Although Thread Pinning is solved, performance-wise not much is observable. ❌ • Virtual Threads do simplify code ✅. • Virtual Threads combined with WebFlux may offer slight performance improvements✅.
44. What next? ➔ Java Virtual Threads have a definite future, but for Android at the moment, only up to JDK17 is supported and no support is available for Java Virtual Threads as a result. ➔ Kotlin Coroutines will stick around for Android for a long time. ➔ In Java Server Side the use of Kotlin Coroutines may go down for simple applications and only where certain specific operations are needed will Kotlin coroutines still likely be needed due to their simplicity and adaptability to reactive frameworks. ➔ For all operations related to structured concurrency, streams and event handling, the usage of Kotlin Coroutines may actually increase as is the case with Mobile Applications in Android. ➔ Maybe coroutines can one day not be used anymore given the potential of Java Virtual Threads even in the case of Android applications, but that isn’t anything for the near future.
45. Questions? I am an inquisitive cat
46. Resources Online • https://kotlinlang.org/docs/coroutines-basics.html • https://openjdk.org/jeps/444 • https://openjdk.org/projects/jdk/21/ • https://www.jetbrains.com/help/idea/supported-java-versions.html • https://discuss.kotlinlang.org/t/coroutines-java-virtual-threads-and-scoped-values/28004/1 • https://developer.android.com/build/jdks Old Slides available: • https://www.scribd.com/presentation/768072685/Could-Virtual-Threads-Cast-Away-the-Usage-of-Kotlin-C oroutines • https://www.slideshare.net/slideshow/could-virtual-threads-cast-away-the-usage-of-kotlin-coroutines/271 727680
47. Source code and documentation • https://github.com/jesperancinha/virtual-thread-coroutine-cooperation (Source code) • https://github.com/jesperancinha/good-story (CPU bound operations comparison) • https://github.com/jesperancinha/sea-shell-archiver (Coding with WebFlux - Mono/Flux/Zip) • https://github.com/jesperancinha/concert-demos-root (Back Pressure testing in Spring WebFlux and R2DBC) • https://github.com/jesperancinha/kitten-house-care-parent (Basics on resilient services)
48. About me • Homepage - https://joaofilipesabinoesperancinha.nl • LinkedIn - https://www.linkedin.com/in/joaoesperancinha/ • YouTube - JESPROTECH - https://www.youtube.com/@jesprotech • Bluesky - https://bsky.app/profile/jesperancinha.bsky.social • Mastodon - https://masto.ai/@jesperancinha • GitHub - https://github.com/jesperancinha • Hackernoon - https://hackernoon.com/u/jesperancinha • DevTO - https://dev.to/jofisaes • Medium - https://medium.com/@jofisaes
49. Thank you!