Hacker News Reader

Comment by heurisko | Hacker News Reader

Given Project Loom hasn't been available, how does it utilise Virtual Threads already?

If you run this on JDK19 with *--enable-preview*, Javalin will use Virtual Threads for the Server ThreadPool (as well as all other ThreadPools it has).

How does it compare to coroutines in Kotlin?

I mean, it sort of doesn't? Coroutines is a whole concept, Virtual Threads can in most cases just replace java.lang.Threads, which is how it's implemented in Javalin. We just swap out the OS Threads for Virtual Threads.

i'd be interested in this too. my guess: virtual threads are slightly more memory efficient and slightly faster, but same ballpark.

now that i think about it i'm pretty sure my guess is completely wrong. memory usage (and thus concurrent-inactives) might be similar, but i expect the virtual threads to be much more efficient.

except if you use the appropriate non-blocking methods! with blocking io, kotlin coroutines are just running in a thread pool.

Project Loom is in preview, and far from available. As far as I can see, Javalin doesn't make use of virtual threads yet.

It does :)

We use reflection to build the Virtual Thread Factory if the user has Loom enabled in their enviroment: https://github.com/javalin/javalin/blob/master/javalin/src/m...

Virtual threads are already available in the current version of the JDK (19) as a Preview feature. Because it's not a preview language feature but a preview API, libraries can use it without compiling with --enable-preview, either with reflection or by having the application supply a virtual thread ThreadFactory, which means they can make use of virtual threads if the application turns preview features on.

Preview language features are different as they require compiling with --enable-preview, which creates a "poisoned" class file that cannot be loaded at all without preview enabled, so preview language features are not recommended for use by libraries, but preview APIs are fine (see JEP 12: Preview Features https://openjdk.org/jeps/12).

Reply on news.ycombinator.com