The mysterious constant pool tag #2

John Rose john.r.rose at oracle.com
Sat Feb 19 00:28:49 UTC 2022


(My apologies for the noise.  Sometimes my mail client presents very old messages to me as if they were new and yet-unanswered.)

On 18 Feb 2022, at 14:27, John Rose wrote:

> On 13 Jan 2021, at 11:28, x4e_x4e wrote:
>
>> I am wondering if anyone here (probably someone involved in the early JVM design) knows the original purpose of tag number 2?
>
> I’ve been on the project since around 1.0, and it was unused at that point.
>
> Googling brings up reasonable discussions like this:
>
> https://stackoverflow.com/questions/46653615/why-is-the-java-class-file-format-missing-constant-pool-tag-2
>
> The name (`CONSTANT_Unicode`) *suggests* that it was at some point intended for something like a UTF-16 version of strings.  There is no further “secret history” that I’m aware of.
>
> *Personally*, I’d like to eventually use that code point for `CONSTANT_Bytes`, sort of like many protocol schemas distinguish Utf8 data strings from byte data strings.  We don’t have a good bytewise constant pool format, and since we now have `CONSTANT_Dynamic` we can consider building interesting things using condy and byte-bundles, with the latter perhaps built out on top of Panama APIs for (read-only) memory segments.
>
> Here is one development of this line of thought:
> https://bugs.openjdk.java.net/browse/JDK-8161256
>
> But it’s not a high priority, obviously.  I think we’d want some language level support for `CONSTANT_Dynamic` constants, and then maybe it would be natural to back-fill byte arrays or hex-strings or Panama segments to a new `CONSTANT_Bytes` carrier.
>
> — John


More information about the jdk-dev mailing list