I would imagine the reason was fast, array like access to the character at index, but some characters won't fit into 16 bits, so it wouldn't work...
So if you have to handle special cases anyways, why not just use UTF-8?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this communityI would imagine the reason was fast, array like access to the character at index, but some characters won't fit into 16 bits, so it wouldn't work...
So if you have to handle special cases anyways, why not just use UTF-8?
Because it used to be UCS-2, which was a nice fixed-length 16-bits. Of course, 16bit turned out not to be enough. They retrofitted UTF-16 in on top.
Originally, Unicode was designed as a pure 16-bit encoding, aimed at representing all modern scripts. (Ancient scripts were to be represented with private-use characters.) Over time, and especially after the addition of over 14,500 composite characters for compatibility with legacy sets, it became clear that 16-bits were not sufficient for the user community. Out of this arose UTF-16.
At the time of Java release UTF-16 hasn't yet appeared, and UTF-8 was not a part of Unicode standard.
For the main part, for the sake of plain and simple future-proofing. Whether it was a misguided reason and the wrong way to go about it is a different question.
You can see some reasons behind some of their design decisions in this document about the 2004 switch to Java 5 and UTF-16, which explains some of the shortcomings as well: Supplementary Characters in the Java Platform, and see Why does the Java ecosystem use different encodings throughout their stack?.
For more details on the pitfalls of using UTF-16, and why UTF-8 is likely to be a better option in general, see Should UTF-16 be considered harmful? and the UTF-8 Everywhere manifesto.
string
a "special" type in Java (much like Array
is), rather than having String
be an "ordinary" class which holds a reference to an "ordinary" array containing the actual characters. Depending upon how a string is generated, UTF-8, UTF-16, or even UTF-32 may be the most efficient way of storing it. I don't think there's any particularly efficient way for an "ordinary" class String
to handle multiple formats, but a "special" type with JVM support could.