JDK 21 Release Notes
Excellent! With virtual threads, all the blocking code I wrote is efficient now :)<p>Less-joking: I&#x27;m so excited for this to start getting adoption. For a pre-release&#x2F;preview feature, Loom already has <i>SO</i> much traction, with most major frameworks already having support for running app&#x2F;user code on virtual threads and one notable project (Helidon Nima) replacing netty with their own solution based on blocking IO and virtual threads. Now I want to see the community run with it.<p>I&#x27;ve always thought async IO was just plain gross.<p>Python&#x27;s implementation is so yucky that after using it for one project I decided that I&#x27;d rather DIY it with multiprocessing than use async again. (I don&#x27;t have any more constructive feedback than that, my apologies, it was a while ago so I don&#x27;t remember the specifics but what has lasted is the sour taste of the sum of all the problems we had with it - perhaps notably that only about 2 people on my dev team of 5 actually understood the async paradigm).<p>netty did it fine. I&#x27;ve built multiple projects on top of netty and it&#x27;s fine. I like event-based-async more than async-await-based-async. But it&#x27;s still a headache and notably I really rather missed the kinds of guarantees you can get (in blocking code) by wrapping the block in try-catch-finally (to e.g. guarantee resources get freed or that two counters, say a requests-in and a requests-out, are guaranteed to match up).<p>But dang am I excited to not do that anymore. I have one specific project that I&#x27;m planning to port from async to blocking+virtualthreads that I expect to greatly simplify the code. It has a lot of requests it makes back and forth (it has to manually resolve DNS queries among other things) so there&#x27;s good chunks of 50-200 ms where I have to either yield (and has gross async code that yields and resumes all the heck over the place) or block the thread for human-noticeable chunks of time (also very gross of course!).