loom

I don't think VTs should be used in practice until Java 22, when it is likely that synchronization (monitors) will be supported [1]. A lot of code may synchronize and be non-trivial to convert to a ReentrantLock, such as ConcurrentHashMap's computeIfAbsent. This can lead to surprising failures outside of the application author's control, such as [2]. Go was originally non-preemptive ("the loops problem"). This was changed in 2019 to preempt at safepoints [3]. The Java team will probably have to do this too [4], but similarly it is low on their priority list and requires feedback. java.util.concurrent is still the basis of good Java concurrency. Some external libraries for reactive or actors might become less popular, but they were always the minority. There will be some improvements with structured concurrency to make that a little bit ea

It's more accurate to say Loom is [a particular type of] continuations in the JVM, which can be used to implement green threads / fibers. You can see the implementation of VirtualThread here: https://github.com/openjdk/loom/blob/fibers/src/java.base/sh... This uses the internal 'one-shot delimited continuation': https://github.com/openjdk/loom/blob/fibers/src/java.base/sh... So, at least in principle, there is scope for other styles of concurrency to be implemented over this.