JDK-8204925 : 6.5: Clarify invokespecial
  • Type: Enhancement
  • Component: specification
  • Sub-Component: vm
  • Affected Version: 11
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2018-06-13
  • Updated: 2019-06-12
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.
Other
tbd_majorUnresolved
Related Reports
Relates :  
Relates :  
Description
Some longstanding complications around invokespecial:

- Historically, a private method could only be invoked by an instruction in the same class. Both `invokespecial` and `invokevirtual` would suit, though `javac` habitually used `invokespecial`. With the introduction of nestmates, the distance between a class invoking a private method and the class declaring the private method can be substantial. In addition, `invokeinterface` was extended in Java SE 11 to be able to invoke a private method in an interface.

- `invokespecial` rehearses an explicit "lookup procedure" for selecting a method. This dispatch algorithm is obfuscatory because it just repeats the logic of [interface] method resolution.

- Since ACC_SUPER has been set for all class files since Java SE 8, it's time to remove it from the main narrative of `invokespecial`. A mention in the "Notes" section, pointing to 4.1, would suffice.

A proposal, which introduces the familiar "method to be invoked" terminology from `invokevirtual`, and avoids a longwinded dispatch algorithm:

-----
The _method to be invoked_ is selected as follows:

- If the symbolic reference names an instance initialization method (��2.9.1), then the _method to be invoked_ is the resolved method (that is, the method found already by successful resolution).

- Otherwise, if the symbolic reference names the current class or interface, then the _method to be invoked_ is the resolved method. (This scenario is known as "direct self invocation".)

- Otherwise, if the symbolic reference names a _direct_ supertype of the current class or interface, then the _method to be invoked_ is the resolved method. (This scenario is known as "direct super invocation". A direct supertype of a class is either the direct superclass of the class, or one of the direct superinterfaces of the class. A direct supertype of an interface is either `Object`, or one of the direct superinterfaces of the interface.)

- Otherwise, the symbolic reference necessarily names an _indirect_ superclass, S, of the current class. The _method to be invoked_ is the method that would be found by successful resolution of the symbolic reference _if it named the direct superclass of the current class rather than S_. (This scenario is known as "re-based super invocation", because the invocation is not based on the indirect superclass named by the symbolic reference, but rather based on the direct superclass.)
-----

(The last bullet implies additional checks arising from resolution. This is a good thing because the ability of the longstanding "lookup procedure" to select a different method (than the resolved method) could be a hole. For example, if the selected method doesn't override the resolved method, there are missing class loader constraints.)
Comments
The changes here should address JDK-8182619. Specifically, resolution checks that occur during re-based super invocation will provide the needed enforcement mechanism.
13-07-2018

Minor spec improvements for JEP 181 are already in motion; there is no need for formal tracking with a P2 bug.
13-06-2018