"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.
2
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
A lot of financial data still moves around in files with fixed-width records and subfields - say, stock ticker in columns 48-54, shares held in 55-68. So "extract ticker" needs char-at-index. You might be able to design a nicer format, but good luck getting big banks to use it.
1
That's a data serialization format, not text in a string. It isn't relevant to this. It's indexed in the way defined by the data serialization format which would probably be bytes. It's not something that needs to be taken into account for handling of text (Unicode) via strings.