RFR: 8339260: Move rarely used constants out of ClassFile [v9]

[Luca Kellermann]

On Wed, 2 Oct 2024 20:24:41 GMT, Chen Liang <liach at openjdk.org> wrote:

> First, some bit of history. These API methods are added before those constants, and this patch did not change the type of these methods or constants.

Sure, makes sense to separate this patch from a potential type change of the methods/constants.

> I believe the methods have restricted return types to be informative: `tag()` is a U1, but it can be interpreted as a char (see [JVMS 4.7.16.1](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.html#jvms-4.7.16.1)) and thus is returned as one. CP tag is a U1 too (see [JVMS 4.4](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.html#jvms-4.7.16.1)) so maybe `byte` is just used out of convenience.

I think `byte` and `char` as the types are a good choice given the way these tag items are described in the JVMS.

> However, we usually use `int` to represent U1, also called unsigned bytes. See [`DataInput::readUnsignedByte`](https://github.com/openjdk/jdk/blob/c43202baf6eb7e49ec458037971a9efa392d053e/src/java.base/share/classes/java/io/DataInput.java#L323) and [`ClassReader::readU1`](https://github.com/openjdk/jdk/blob/c43202baf6eb7e49ec458037971a9efa392d053e/src/java.base/share/classes/java/lang/classfile/ClassReader.java#L133). Guess that's why we used `int` for the constants. (Also, note that byte and char are all [erased to int](https://download.java.net/java/early_access/jdk24/docs/api/java.base/java/lang/classfile/TypeKind.html#computational-type) in bytecode, so this has little practical effect and that might be why I didn't bother to change these)

One scenario where the unequal types of the methods and constants _does_ have a practical effect are JVM languages that don't have [binary numeric promotion](https://docs.oracle.com/javase/specs/jls/se23/html/jls-5.html#jls-5.6) for their [numerical equality operators](https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.21.1).

This is the case for Kotlin's [value equality expressions](https://kotlinlang.org/spec/expressions.html#value-equality-expressions). This Kotlin code [would not compile](https://pl.kotl.in/A9D1WDdS8):

fun isArray(a: AnnotationValue): Boolean {
    return a.tag() == AnnotationValue.TAG_ARRAY
}

Instead you would have to write [this code](https://pl.kotl.in/qSrwSIL39):

fun isArray(a: AnnotationValue): Boolean {
    return a.tag() == AnnotationValue.TAG_ARRAY.toChar()
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20773#discussion_r1790562651