JDK-8287047 : 4.4.2: Relax checking of some constant pool entries that name a class/interface
  • Type: Bug
  • Component: specification
  • Sub-Component: vm
  • Affected Version: 18
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-05-19
  • Updated: 2022-06-07
  • Resolved: 2022-06-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 19
19Fixed
Related Reports
Relates :  
Description
A constant pool entry of kind CONSTANT_Methodref should refer to a method in a class type, while a constant pool entry of kind CONSTANT_InterfaceMethodref should refer to a method in an interface type. Historically, the spec of these two constant pool kinds was strict about this. Notice the two "must be" clauses in the following:

-----
class_index

    The value of the class_index item must be a valid index into the constant_pool table. The constant_pool entry at that index must be a CONSTANT_Class_info structure (ยง4.4.1) representing a class or interface type that has the field or method as a member.

    In a CONSTANT_Fieldref_info structure, the class_index item may be either a class type or an interface type.

    In a CONSTANT_Methodref_info structure, the class_index item *****must be***** a class type, not an interface type.

    In a CONSTANT_InterfaceMethodref_info structure, the class_index item *****must be***** an interface type, not a class type.
-----

Checking that the class_index item of a constant pool entry actually refers to a class type rather than an interface type (or vice versa) requires eager loading of the referenced type, in particular during format checking of the class which contains the constant pool entry.

This eagerness is at odds with the laziness of resolution for symbolic references derived from constant pool entries. In addition, the rules of resolution already take ownership of the class-versus-interface question, in 5.4.3.3 ("If C is an interface, method resolution throws an IncompatibleClassChangeError.") and 5.4.3.4 ("If C is not an interface, interface method resolution throws an IncompatibleClassChangeError.").

Accordingly, the 4.4.2 text for class_index should be relaxed so that, during format checking, no ClassFormatError is due if the wrong kind of class/interface type is referenced:

-----
    In a CONSTANT_Methodref_info structure, the class_index item *****should be***** a class type, not an interface type.

    In a CONSTANT_InterfaceMethodref_info structure, the class_index item *****should be***** an interface type, not a class type.
-----
Comments
I'll add that I think it's reasonable in the context of the entire specification to understand that "must be a class type" was a poor choice of words here, but was not intended to suggest that the JVM actually go and load some additional class files to validate it. (Actual triggers for class loading are pretty explicitly spelled out elsewhere.) This phrase is just one of many cases in which JVMS Chapter 4 is not careful with words like "must", and it will not be productive to try to identify and apply spot fixes for all of those. Instead, a more comprehensive review and revision will be provided by JDK-8267650.
19-05-2022