Yeah, I mean now we can start using VTs on any system / lib without being worried of pinning. Isn't this a "huge" deal? Why is the community not shouting from the rooftops about this?
Theoretically it means, Java has now bettered Node.js "async / await" approach and that too without the two colored function approach. One process can now spawn thousands of threads to service IO and none of those threads are blocking / waiting (and with this release there is no gotcha / pitfall remaining).
Not mention all the Netty / reactive libraries have no use now (not that I am complaining).
Indeed, the relief is great. However, there are relatively few users of virtual threads yet. Even fewer are keeping up with the releases. Those using it in production already managed to work around the issues or have given up on it. We will hear more when Java 25 is released (which will be an Oracle LTS version) or if a backport to LTS 21 happens.
> Not mention all the Netty / reactive libraries have no use now (not that I am complaining).
Netty uses an eventloop/async paradigm. The benefit of that style is you do not need any locking (within the same eventloop). How does virtual threads make that of no use?
No need for complex async / event loop stuff. VTs can be spawned by millions and they will not block the thread (/CPU) while doing IO, in this (win-win) scenario there is no value in doing complex (and 2 colored) async programming.
You didn't answer the question though. When I use a single threaded event loop with async style, I don't need to use any locks. It isn't about efficiency, it is about low complexity because I don't need to reason about shared state.
Is it good practice or not to use locking semantics if you use virtual threads?
It is totally fine to use locking with virtual threads. Of course you don't need it if you don't have to restrict access to shared resources in the first place (for example a connection pool or a datastructure with internal invariants that have to be maintained) or if lockless alternatives are available.
Theoretically it means, Java has now bettered Node.js "async / await" approach and that too without the two colored function approach. One process can now spawn thousands of threads to service IO and none of those threads are blocking / waiting (and with this release there is no gotcha / pitfall remaining).
Not mention all the Netty / reactive libraries have no use now (not that I am complaining).