If you've been following the development progress, they've gotten the VM side largely ironed out and under testing. Nothing on the language side has been polished yet though.

As an honest estimate, I'd give about 2-4 more years. But it's definitely further along than I thought it would be.

See: https://cr.openjdk.java.net/~briangoetz/valhalla/sov/

Value types and Loom (lightweight threads) are two things that will shape Java in profound ways for years to come.

2-4 years for value types seems quite long but the changes to the spec to accommodate value type is much more broader in scope so that’s understandable.

Loom question: I gather that it basically has implicit awaits, so how do you “force no-await” so you can run operations concurrently?

Spawn new threads (and then join them).

Is than an OS thread or a Loom-thread though?

If it’s an OS thread, then that won’t scale and defeats the point of using Loom (though it does still reduce the overall system load).

If it’s a Loom-thread then doing `.join()` is the same thing as doing an `await` - in which case it’s silly to not just have a `.dontJoinJustYet()` method that’s available for every Loom promise.

You pick the thread implementation, but clearly a virtual thread would be more appropriate. And yes, join is semantically the same as await, but it fits with the design of the platform. And also yes, there are convenience methods for spawning threads and joining them, such as ExecutorService.invokeAll/invokeAny.

How do you think Loom would impact reactive projects such as Spring Reactor, Vertx and R2DBC?

I don't know. Those who genuinely enjoy reactive frameworks will still be able to use them, but those that don't won't need to to get similar scalability benefits.

Spawn virtual threads

Good question. Something that @pron can answer better

There has been significant progress though. Especially since the 6 month release cycle. Lots you can do with Records now https://benjiweber.co.uk/blog/2020/09/19/fun-with-java-recor...