Features of Project Loom incorporated in JDK 21

Congrats to Ron Pressler (pron at HN) and the team. Who worked on it for so long, ever since the Quasar library.

Nice, Project Loom is often summarised as just incorporating the main feature of Virtual Threads however it will also add a whole bunch of other features or improvements for doing tasks concurrently and not having to worry about blocking IO or race conditions like you would have in the past.<p>Some useful code examples are here to play around with <a href="https:&#x2F;&#x2F;github.com&#x2F;nipafx&#x2F;loom-lab">https:&#x2F;&#x2F;github.com&#x2F;nipafx&#x2F;loom-lab</a>

There are some fairly major Java backend libraries that are founded almost entirely on async-type APIs. Eg, Vertx, Quarkus, Micronaut, etc.<p>I am interested to see how a widespread move to virtual threads, which for them is somewhat existential, affects their futures (pun intended). Also what backend libs that are founded on virtual threads emerge and supplant them.

Info on what Project Loom is: <a href="https:&#x2F;&#x2F;cr.openjdk.org&#x2F;~rpressler&#x2F;loom&#x2F;Loom-Proposal.html" rel="nofollow noreferrer">https:&#x2F;&#x2F;cr.openjdk.org&#x2F;~rpressler&#x2F;loom&#x2F;Loom-Proposal.html</a>

Does anybody know what this will mean for the already existing green threads implementations in e.g. Kotlin and Scala Cats? Will these benefit from project Loom, or are they somehow incompatible?

Other than cooperative threading: they are also adding a more versatile switch statement, with some form of pattern matching <a href="https:&#x2F;&#x2F;openjdk.org&#x2F;jeps&#x2F;441" rel="nofollow noreferrer">https:&#x2F;&#x2F;openjdk.org&#x2F;jeps&#x2F;441</a><p>But it still falls short of deconstruction patterns of Scala, though that is something that they want to do in the future (see &#x27;Future Work&#x27; section)<p>i think that Scala is driving a lot of progress: (for example java adopted streams, probably inspired by Scala)

It&#x27;s great to see this, but it&#x27;s not going to make me want to go back to Java from Go. In Go, everything is built with this sort of concurrency from the ground up. This makes everything fit together very nicely without the cognitive overhead and dissonance you have to work through with the Java libraries of various vintages and approaches.

At first I misread and wondered what Project Loon[1] could possibly contribute to JDK 21.<p>[1]<a href="https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Loon_LLC" rel="nofollow noreferrer">https:&#x2F;&#x2F;en.m.wikipedia.org&#x2F;wiki&#x2F;Loon_LLC</a>

any metrics to compare this to say streams or any other OS based parallelisation?

A good step forward and nice that it&#x27;s in the next (Oracle) LTS version. But is it too late? NodeJS started cleaning up by pushing async-for-all over a decade ago. Then Go came along and did the same thing but with a simple statically typed language. The Java world developed async server frameworks + GraalVM native image in response and now will be able to incrementally phase them out, but Java lost significant ground server-side because it took so long to identify and respond to these moves by competitors.<p>The question is now whether Java will regain some of that lost ground, or whether people came for the async but stay for the &quot;isomorphism&quot; (same language in both browser and server) &#x2F; AOT compilation model.<p>My gut says it&#x27;s not too late for them and devs do engage in a kind of continuous rolling evaluation of platforms. Once Java 21 launches people might start to re-evaluate Java vs Node and once Loom is fully supported in native images, you might start to see people re-evaluate Java vs Go at least. Where by &quot;Java vs&quot; I really mean &quot;JVM languages vs&quot; like with Kotlin, Scala and Clojure as well. Or maybe even Loom will be compatible with GraalJS and then you can do fully blocking programming with Node-style efficiency but on the JVM.

Aka green threads.

Basically you ignore a bunch of the work done for async, callbaks, etc and go back to making a new &quot;thread&quot; and handling a request.