Why do Java classfiles (and JNI) use a "Frankenstein's monster" encoding crossing UTF-8 and UTF-16? [closed]

Question

It seems like using either UTF-16 or UTF-8 would have been a lot more straightforward than what Java decided on for storing strings in classfiles and JNI payloads. It is a monstrosity that combines aspects of UTF-16 and UTF-8 formats. Is there any rational explanation for choosing this option?

See: https://docs.oracle.com/en/java/javase/13/docs/specs/jni/types.html

It seems to me that this unique format is what you would get if you started with UTF-16, then passed that through a "UCS-2 to UTF-8" converter... in other words, something you'd only produce by mistake... a variation of https://en.wikipedia.org/wiki/Mojibake (albeit one that is lossless).

I have since discovered that there is a name for this format: https://en.wikipedia.org/wiki/CESU-8. (However the Java string format is technically a small extension of CESU-8 to add "overlong null bytes" and this extended version of CESU-8 has its own [vague] name: ‘Modified UTF-8’).

Answer 1

It seems to me that this unique format is what you would get if you started with UTF-16, then passed that through a "UCS-2 to UTF-8" converter.

As I understand it:

From a modern viewpoint UTF-16 and UCS-2 are different encodings, but historically it makes more sense to think of them as different versions of the same encoding. What is now called "UCS-2" was historically just called "Unicode".

Back in 1989 the ISO had proposed a Universal character set as a draft of ISO 10646, but the major software vendors did not like it, seeing it as over-complicated. They devised their own system called Unicode, a fixed-width 16-bit encoding. The software companies convinced a sufficient number of national standards bodies to vote down the draft of ISO 10646 and ISO was pushed into unification with Unicode.

This original 16-bit Unicode was adopted as the native internal format by a number of major software products. Two of the most notable were Java (released in 1996) and Windows NT (released in 1993). A string in Java or NT is, at its most fundamental, a sequence of 16-bit values.

UTF-8 was devised in 1992, as a format for encoding Unicode/UCS values as a self-synchronising sequence of bytes in a form suitable for use in Unix filenames, on the web and in other ASCII-based environments. In most cases, it was also smaller than the 16-bit fixed-width representation.

It became clear that 16 bits was not enough. ISO wanted to expand the code space to 32-bit. Unicode did not like this idea because of memory usage concerns and because software was already using 16-bit. There was a compromise: Unicode 2.0 in 1996 expanded the code space to just over 20 bits, and introduced UTF-16

UTF-8 was able to encode all of the new characters directly, and this was the standard way to do things. However, it did create problems for software that used UCS-2 internally and UTF-8 as a storage format.

Adopting "standard UTF-8" for such software would cause compatibility issues. If a new version of the software wrote a supplementary character, the old version of the software would have no way to handle the 4-byte sequence. It would likely either give an error, or mangle the text.

Whereas by using the UTF-16 encoded in UTF-8 format, there would be no need to change the routines that saved and loaded strings at all. There would be no need to change formats at all. From the perspective of old software, the new characters would just be regarded as pairs of unknown characters.

Java's variant has one other change. It uses a 2-byte code for code point zero. My understanding is that this was done to allow the string to be processed safely with standard C string handling routines, even if the Java string contained null characters.

Answer 2

At the time Java was designed, it was not at all clear that UTF-8 would emerge as the most commonly used Unicode representation. It was generally assumed that "Unicode" meant "two byte characters", as implemented for example in the Win32 API of Windows NT (released 1993). This can also be seen in the Java 16-bit char type (released 1995). Java and the JVM were originally completely implemented using 16-bit characters. Java began life as the "Oak" programming language in 1991, but it's hard to say how much changed between then and 1995. The precursors to UTF-8 (FSS-UTF) were only invented around 1992-1993. UTF-8 itself was not finally adopted by the IETF until 1998.

As it turned out, 16-bit characters was not enough for what Unicode eventually became, which meant Java had to expand their representation while still being compatible with the older 16-bit character representation. I can't find specific references to when Unicode "surrogate pairs" were developed, but they were introduced to Windows in Windows 2000.

In short, Unicode character encodings were going through a number of different transformations in the 1990s. Java and Windows are two major pieces of software developed during that time, and the legacy of their various choices are still very visible today.

Answer 3

The main thing is that a Java string with their modified UTF-8 encoding can have no embedded null (zero) bytes. This is for C compatibility (in the implementation, and in the JNI) java strings are C-strings with null termination). But the code point \000 is valid UTF-8. They just chose to use a non-standard encoding of the code point \000 and IMO UTF-8 should have done it that way anyway given the prevalence in the real world in production of C-style APIs.

The other difference - no 4byte encodings - is most likely because in those days there was nothing interesting in that part of the Unicode spec - beyond the BMP - and thus it was an implementation complexity of no value. In those days implementation complexity was a big deal because of where Java was originally intended to be used/deployed: toasters and other devices with dinky computing resources.

Internally they used fixed size 16 bit characters because the approach Sun adopted for Unix - fixed size 32 bit characters - was totally a non-starter for their use cases. And nobody uses variable length coding internally because multi-byte character sets are a correctness and performance nightmare.

Answer 4

[Throughout the remainder of this post, I'm going to use "UCS-2", "UCS-4", "UTF-8" (etc.) as they're current interpreted, even though most of those terms didn't exist at the time.]

When Java was new, there were basically only two choices available. Unicode promised (but in the long term, didn't deliver) encoding everything in 16-bits per code point (UCS-2).

The alternative was ISO-10646, which didn't specify encoding, as such. But it used 32-bit code points, and lacking a specification of anything else, at the time that was generally interpreted as meaning UCS-4.

Each of those has problems, but the problems with ISO-10646 were serious in the short term, while the problems with Unicode were much longer term.

The big controversy with Unicode at the time was something called "Han unification". Chinese and Japanese alphabets contain quite a few similar characters. Han unification used a single code point for both the Chinese and Japanese versions of many of those. Quite a few people (especially Chinese and Japanese people) didn't like that much (like: hated it with the blinding fury of a supernova).

The big problem with ISO-10646 (as it was seen at the time) was that it needed 32 bits per character. Hard drive prices were falling to the point that using more space for text was seen as somewhat reasonable, but quadrupling the size of nearly all text files was generally seen as just a bit too much.

UTF-8 had been invented at the time, but it wasn't particularly well known. Worse, Shift-JIS (among others) had created a strong distaste for variable width encoding schemes among many programmers. While UTF-8 avoided many of the worst problems, the simple fact that it was a variable-width encoding was enough for many programmers to reject it out of hand.

So, at the time Sun was faced with two (or conceivably three) choices: ISO-10646/UCS-4, ISO-1646/UTF-8, or Unicode/UCS-2.

I'm going to go on record as saying that if they'd chosen either of the ISO-10646 options, Java would have been still-born--long since dead and forgotten except in a footnote in an appendix about "otherwise promising projects killed by a single mistake that was understandable but still utterly bone-headed given the constraints of the time".

So in the short term, UCS-2 was really their only choice. Not a great choice by any means, but at least one that allowed Java to remain viable long enough for its early choices to turn into problems people still cared about decades later. And yes, they were faced with a bit more than just UCS-2 vs. UTF-16¹. By the time they dealt with making that move, quite a bit of software had been written taking advantage of lots of quirks in both UCS-2 itself, and how Java happened to implement parts of it. They needed to account for both, which resulted in something that's fairly kludgy at best.

---

^{1. Or at least a fairly reasonable approximation of each.}

Answer 5

TL;DR: conforming UTF-8, as presently defined, cannot encode some valid (to Java) Java Strings, on account of disallowing code sequences encoding surrogate code points.

---

In the beginning, Java chose 16-bit Unicode code points for representing characters. That was perhaps short-sighted, but 16 bits was sufficient for all of Unicode at the time. Correspondingly, Java's primitive char type is 16-bits wide, and, uniquely among Java's primitive types, it is unsigned.

Such a representation is a bit unwieldy for a C-based JVM implementation, however, because raw Java character data tends to contain lots of null bytes, making it unsuitable for use with C string functions. To much the same degree, the Java representation also tends to be larger, which is unfortunate for storage-constrained devices. Such devices were definitely among Java's initial targets.

The UTF-8 of the time addressed both of these issues, which made it a good choice for the native-code representation of Java string data. It's unclear why Sun chose a variant encoding of code point 0 (which still contains a null byte), but there are at least two plausible explanations:

• it helps distinguish between embedded Java char's with value 0 and C string terminators; and
• it makes certain kinds of potential JVM string-handling bugs easier to troubleshoot.

These are not mutually exclusive.

And since the Unicode code point space did not provide for code points wider than 16 bits, and no code points were reserved (e.g. for surrogates), that one variant encoding was the only difference between Java's character encoding and standard UTF-8. Moreover, it's a pretty benign difference, because a UTF-8 decoder has to go out of its way to reject the Java variant-zero. A naive UTF-8 decoder will just decode it to code point 0, which is exactly what it in fact represents.

So Java pretty much chose UTF-8, not some amalgamation. And then UTF-8 was yanked out from under it.

When Unicode widened the code point space and created surrogate pairs and UTF-16, it also specified that UTF-8 encodings of surrogate code points were invalid code sequences. That made Java's (and others') existing practice non-conforming. But why should Sun have cared? They had working software, and the character representation Java used internally was, after all, internal. They stuck with it.

And Sun didn't particularly pivot on Strings, either. To this day, they are sequences of 16-bit unsigned integer values corresponding to Unicode code points in the BMP (including surrogates). Java does produce and consume UTF-16 surrogate pairs inside strings, but it does not forbid arbitrary placement of surrogate code points within. In this sense, Strings' character-data nature is not quite complete. It was much later that Java introduced code-point-based interfaces to Strings, which must effectively perform UTF-16 decoding of the character data, and the traditional char based interfaces are still available and widely used.

So, Sun just continuing to do what they were already doing is what moved Java from slightly-quirky-if-that UTF-8 to the bona fide-variant UTF-8 now known as CESU-8. But they couldn't move to UTF-8 even if they wanted to do, because Java Strings' allowance for unpaired surrogates makes them impossible to encode in conforming UTF-8. I suppose it's a bonus that it's easier to transcode Java String data to CESU-8 and back, exactly because there is a one-to-one correspondence between CESU-8 code sequences and Java chars. No interpretaion of surrogate pairs is required.

Answer 6

Unicode for Java is (or at least was at the time) strictly 16 bit character - as Unicode was as well a 16 bit code space. Within this 16 bit code surrogate code points (pairs) opened a way to extend the 2^16 character points by another 2^20 ones.

CESU-8 in turn is an encoding that for one allows to use the same address space, but at the same time guarantees that any conversion to Unicode will result in one or two valid 16 bit characters. As a result any program using a 16 bit character type will be able to handle them.

It essentially transposes the same mechanic 16 bit Unicode uses to UTF-8.