Hacker News new | ask | show | jobs
by heurisko 1354 days ago
Given Project Loom hasn't been available, how does it utilise Virtual Threads already?
2 comments
tipsee 1354 days ago
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).
link
daveidol 1354 days ago
How does it compare to coroutines in Kotlin?
link
tipsee 1354 days ago
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.
link
stefs 1354 days ago
i'd be interested in this too. my guess: virtual threads are slightly more memory efficient and slightly faster, but same ballpark.
link
stefs 1351 days ago
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.
link
stefs 1351 days ago
except if you use the appropriate non-blocking methods! with blocking io, kotlin coroutines are just running in a thread pool.
link
oweiler 1354 days ago
Project Loom is in preview, and far from available. As far as I can see, Javalin doesn't make use of virtual threads yet.
link
tipsee 1354 days ago
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...

link
pron 1354 days ago
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).

link