That code makes zero sense in Unicode. First question how are representing your umlauts, followed by Zero Join Width Characters.
You never work on characters, you work on grapheme clusters or whatnot but never characters.
You never work on characters, you work on grapheme clusters or whatnot but never characters.
It was always O(n).
Of course assuming you aren't using UTF-32, which has its own set of problems (BE or LE), and sees little usage outside of China.
Saying it works fine if you ignore errors and avoid edge cases is just a clever rephrashing of it worked on my machine.
Plus Emojis are Unicode U+1F600 and above, so even in Western language you are bound to find such "exceptions" .
That’s how you write hashing algorithms, checksums, and certain trivial parsers.[0]
But most importantly, right or wrong, this code is out there, running today, god knows where, and you do not slow it down from O(n) to O(n^2).
That's changed in the newer versions, because String has a `byte[]` not a `char[]`, but it was just fine. A hash algorithm can take in bytes, characters, ints, it doesn't matter.
In Java, you don't get access to the bytes that make up a string, to preserve the string's immutability. So for many operations where you might operate on bytes in a lower level language, you end up using characters (unless you're the standard library, and you can finagle access to the bytes), or alternately doing a byte copy of the entire string.
I admit, checksums using characters are a bit weird sounding, but they should also be perfectly well-defined.