"you don't need to know about the implementation" twitter.com/richardstartin
This Tweet is unavailable.
2
1
28
Conversation
Replying to
Seems this was a regression caused by the complexity of Compact Strings which has been fixed for a while now.
bugs.openjdk.java.net/browse/JDK-817
Maybe one day Java will get proper strings instead of pretending that their UCS2 strings are UTF-16 and that UTF-16 is actually a good idea.
1
5
Java just ossified around all the worst ideas of the 90s so I wouldn't count on it.
1
1
I'm optimistic JavaScript will get proper strings because WebAssembly is UTF-8 focused and they're making good decisions about how interoperability works with JavaScript despite it upsetting people invested in UCS2.
Python switched from UCS2 to UCS4 which was a dumb decision...
1
2
Python took that same multiple string representation approach and browsers did the same for JavaScript. The strings are always fixed size units in Java / JavaScript / Python and they bloat themselves up to a larger unit if you add a single character from the range requiring it.
That's so obviously a bad approach and buys you nothing of value. It's so baffling to me that everyone bought into the idea that "indexing nth character" was a meaningful operation for strings and designed everything (badly) around that.
2
1
Is there some important benchmark that does this? Because people who know about unicode.org/reports/tr29/# understand this. A cursor that scans byte array and advances by grapheme cluster makes more sense.
1
2
Show replies
I think the most reasonable approach today would be for most languages to use UTF-8 internally, yet natively support UTF-16 and UTF-32 as well, with easy conversion. Trying to settle on *one* isn't going to work because that boat has already sailed ⛵
2
You can just implement it as converting to UTF-16 or -32 at the last minute when passing to a legacy interface that requires one of those (with the inherent possibility of a storage exception).
1
Show replies