That's the point of Java's virtual threads, basically nothing* will block. The JVM can simply replace a blocking user IO call to an async one under the hood, and in the meanwhile schedule another virtual thread to work. When the IO is ready the suspended thread might get continued.
In your example the thread is not blocked but the callers are blocked.
There is more to async/await than simply keeping os threads unblocked, they also provide a mechanism for keeping callers unblocked and synchronizing async contexts(parallel or concurrent).
Is Loom addressing this need? Otherwise it's Goroutines(or any green threading solution) without channels and select. The ecosystem will fracture around solutions to address the boiler and future chaining pains.
Java allows not blocking callers using Futures or callbacks for a long time.
As well as Promises and callbacks were available in Javascript before async / await.
var executor = Executors.newVirtualThreadPerTaskExecutor();
;; or, for old Java
var executor = Executors.newSingleThreadExecutor();
Future<Integer> f = executor.submit(someFunc);
What is relevant in the new Java VirtualThreads and Javascript async / await
is the possibility to write simple synchronous code, with the performance
similar to callback-based asynchronous code.
* FFI has to be pinned, so it will block