On Wed, 2 Oct 2024 19:16:08 GMT, Luca Kellermann <d...@openjdk.org> wrote:
>> Chen Liang has updated the pull request incrementally with one additional >> commit since the last revision: >> >> AbstractPoolEntry is broken too > > src/java.base/share/classes/java/lang/classfile/AnnotationValue.java line 482: > >> 480: * describe the possible return values of this method. >> 481: */ >> 482: char tag(); > > Why is the type of the constants different from the return type of this > function? 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. 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. 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) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20773#discussion_r1785208822
