[wiseowise]

And how is that any different from Kotlin coroutines if you still need to call Thread.startVirtualThread?

[pron]

1. These are actual threads from the Java runtime's perspective. You can step through them and profile them with existing debuggers and profilers. They maintain stacktraces and ThreadLocals just like platform threads.

2. There is no need for a split world of APIs, some designed for threads and others for coroutines (so-called "function colouring"). Existing APIs, third-party libraries, and programs — even those dating back to Java 1.0 (just as this experiment does with Java 1.0's java.net.ServerSocket) — just work on millions of virtual threads.

Normally, you wouldn't even call Thread.startVirtualThread(), but just replace your platform-thread-pool-based ExecutorService with an ExecutorService that spawns a new virtual thread for each task (Executors.newVirtualThreadPerTaskExecutor()). For more details, see the JEP: https://openjdk.java.net/jeps/425

[ferdowsi]

Kotlin coroutines are colored and infect your whole codebase. Virtual threads do not.

[wiseowise]

You can mark everything suspend and there's no difference.

[pjmlp]

Native VM support instead an additional library faking it, and filling .class files with needless boilerplate.