Testing whether constant pool entries match nominal descriptor objects

[Chen Liang]

Hi all,
I observed that a frequent pattern in class file transformation is that we test if a call matches given descriptors, and we subsequently replace it with a new call. For example, we might want to redirect calls to MethodHandle.Lookup to a proxy class that performs run-time remapping of incoming class, method, or field names.

Currently, the best way to test for such call patterns is to examine their owner class, name, and type individually. For example, user would check:

owner.name().equalsString("java/lang/invoke/MethodHandles$Lookup")

Which has these problems:

  1.
Users might not be aware of this approach; they might do things like
owner.asInternalName().equals(...)
which will suffer from performance penalties due to the eager evaluation of internal names.
  2.
Users might get the internal name wrong, or confuse internal names with descriptors.

As a consequence, I propose addition of "equalsSymbol" method to these classes:
 - ClassEntry::equalsSymbol(ClassDesc)
 - MethodTypeEntry::equalsSymbol(MethodTypeDesc)
 - ModuleEntry::equalsSymbol(ModuleDesc)
 - PackageEntry::equalsSymbol(PackageDesc)
 - StringEntry::equalsString(String)
 - Utf8Entry::equalsSymbol(ClassDesc) // Might consider rename to "equalsTypeSymbol" to avoid confusion with ClassEntry?
 - Utf8Entry::equalsSymbol(MethodTypeDesc)

With the following purposes:

  1.
To help such usages of descriptor matching tests to be less error-prone
  2.
To allow faster comparison with reduced processing on many constant pool entries

Please don't hesitate to share your thoughts about this proposal, such as renaming suggestions or problems with these new APIs.

Regards,
Chen Liang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250227/a6d3be5b/attachment.htm>