I definitely enjoyed this writing style more than a lot of the recent cf blog posts. Cool article!

Really cool, shame that strings can’t be fully indistinguishable like Integer despite their immutability

One misconception I had was that with value objects we could simply use `==` for comparison. But it looks like there's lots of gotchas with this especially if the value class has String fields for one or more fields. For example, comparing two ZonedDateTime value objects may be fine with == because I believe the JDK team ensured the Strings that represent the ZoneIds are always the same reference.

We have tons of wrapper classes in our codebase which seem ideal as value objects. For example, instead of passing around "String emailAddress", we have a wrapper class EmailAddress. While we can now make our EmailAddress class a value object, we cannot do "==". Unlike ZoneId in which there's a fixed set and you can intern all ZoneIds in the string pool, email addresses are unique and trying to intern all email addresses would be a bad idea. So it seems like using .equals is here to stay even for these types of basic classes.

I don't think there's a lot of gains to be had for strings. Perhaps if you are dealing with a very large amount of small strings then it could be useful, but once you get past a few characters strings it's faster to just send around a reference anyways.

Is there a theoretical reason why they can’t?

As a layman I would assume nothing is preventing it, other than the large amount of effort it would take to implement.

From what I gathered the core problem is flattenability. It is backed by a dynamic array and you would need real templating to remove the indirection.

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…

No theoretical reason; It's backward compatibility/internal technicalities, as they mention in the JEP.