[kaba0]

> unsigned types, no plans to implement in java (though IIRC it was originally planned as part of valhalla)

Not too comfortable to use functions that will compile to efficient byte code exists for them, but with the definitely coming Valhalla, it will be trivial to create a custom primitive class for unsigned ints.

> async/await

With project Loom, it will avoid the mistake of function coloring that async introduces. In a managed language, why not let the runtime automatically transform blocking calls to non-blocking, when it already knows what’s up?

[shartacct]

> With project Loom, it will avoid the mistake of function coloring that async introduces. In a managed language, why not let the runtime automatically transform blocking calls to non-blocking, when it already knows what’s up?

Not saying it's a good or bad thing, but .NET and C# by extension has had these features for years (decades in some cases) while the only thing java has are half-baked prototypes and plans to 'maybe' implement things. In many cases these plans just get endlessly pushed back and new java major versions just become a pile of simple bugfixes which in the past were just pushed as minor jre updates.

[kaba0]

It’s not like async/await is a must, they are on the surface just syntactic sugar.

In the background, coroutines are a strictly less useful feature than what will happen with Loom, and please show me any “promised feature” that were only half-baked prototypes? We do have one half of Valhalla (vector api) under an experimental flag with JDK 17 already, several language related JEPs were shipped already. That Loom and primitive classes take their time only mean that they are not vaporware, because these are actually ridiculously complex problems.