On Tue, 11 Feb 2025 08:03:23 GMT, Adam Sotona <asot...@openjdk.org> wrote:
>> The ClassFile API promotes usage of constant nominal descriptors over >> literal strings. However, for `class` file parsing, currently the efficient >> way to check if a constant pool entry matches a desired descriptor is via >> unrolling them back to strings. However, string unrolling is ugly, and often >> times confusing, such as internal names versus field descriptors. >> >> As a result, I propose to provide new methods that compare constant pool >> entries with the potential symbolic descriptors they represent. This is no >> less efficient as checking raw string equality, avoids exceptional failure >> behaviors of conversion to symbolic descriptors, and avoids potential >> programmer errors stemming from raw string handling. See the CSR for a full >> story. > > src/java.base/share/classes/java/lang/classfile/constantpool/Utf8Entry.java > line 95: > >> 93: * @since 25 >> 94: */ >> 95: boolean equalsSymbol(ClassDesc desc); > > Ambiguity of class internal name vs. descriptor serialization might be > confusing: > > classEntry.equalsSymbol(classDesc) != > classEntry.name().equalsSymbol(classDesc) > > I think it should be more highlighted to avoid mistakes. I think the best way to avoid these confusions is, in addition to specifying in the docs, renaming the methods on `Utf8Entry` to include the word "descriptor", like `equalsDescriptorString`, but I fear this method name might be too long. If the `equalsDescriptorString` on `Utf8Entry` is too inconvenient, a remedy may be to add `matches(String, ClassDesc)` or `matches(String, MethodTypeDesc)` to NameAndTypeEntry and/or MemberRefEntry. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23548#discussion_r1951191457
