> Records, switch expressions, multi line strings and that is only language changes.

None of those are features, they were desperately needed shorthands for common java idioms. This is like calling braceless if/for/while statements 'features', when they're purely syntax sugar that has fallen out of favor completely because there's been several major security vulns found in major projects due to their use and development oversight/code review failure (https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-got...), to the point where most companies ban writing them.

Just off the top of my head:

* LINQ. Added to C# in 2007, Java didn't get streams until 2014.

* structs/value types, implemented in net framework and net core for 15+ years, but not present in java 17. Some oracle engineers have been working to implement them under project valhalla but it seems to be vaporware at this point after 8+ years of work.

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

* async/await

At the feature level Java is stuck in the mid 2000s. Nobody wants to do the actual work on keeping it competitive.

> async/await

Thank God they didn't shove this crap in. When Loom ships (I believe the next LTS is their target, more or less), JVM will have the same concurrency story as Go does, without blue/green function split like in C#.

> 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?

> 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.

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.

With your explanation everything is just a shorthand. All you really need is NAND.

Streams are a library feature, records are a language feature. Streams could be implemented outside, records could not (no lombok abominations are not records).

comparing braces to records/multi line strings/switch expressions is so funny that I won't even comment on that.