Trust me. That's a common argument used when java introduces new features. Wait you see the same argument once value classes come to jdk 28.

Yeaaah. They are going to introduce approaches for the programmer to decide if tearability is allowed or not. Already there are internal annotations for fields and types to enable it that probably will become a language feature in future.

The Java way was always to let library designers decide how a type is used. I personally think this is the sensible one.

They are researching to have immutable arrays. Also multifields (stack allocated arrays as fields in value classes). So, there is a possibility.

The problem is not that the array is mutable, but that the size of the array may differ for different strings. (In fact, it usually* does differ if the string length is different).

This makes it impossible to flatten - as the VM needs to know the total size when creating the memory layout for a class...

* (with a small exception: if the strings use different coders, one can be twice as long and the backing arrays would still have the same size)

Indeed. At this point you’d need to bring the size of the string into the type system (C++ Templates we meet again!) but then you look at a solution worse than the problem…