Seems like I get served gibberish bytes in the response body when visiting this site! I promise I’m not a bot :(

Yep. Doesn't work. Just a bunch of garbage. This is anti-accessibility and user hostile.

Old versions of Safari could get that. I am being an opinionated ass and practicing hostile security paternalism because the safety and bot-filtering benefits outweigh the cost of supporting old clients. I do even stranger things.

Doesn’t work on mobile Safari latest version either. At least not when using iCloud private relay.

iCloud private relay was a blind spot. Working out how to let those proxy ranges in. (I blocked all the CDN's but this is more of a surgical carve-out for specific Apple designated ranges) Extracting those carve-outs now.

Edit: Applied carve-outs for Apple's iCloud private relay proxies. (I think)

If anyone is curious why I have to block CDN's, they permit abusive behavior, abuse of their workers (apps) and other layers of their networks. Maybe in a few decades they will get on it.

Maybe they could ask Gemini to fix their awful website to not crash on my phone!

This website is absolutely terrible in iOS Safari, super glitchy.

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.