-
Bug
-
Resolution: Fixed
-
P2
-
None
-
Verified
The invokespecial specification needs to be modified to address the following.
(For clarity, I consider the following cases of the invokespecial method. i) an instance initialization method, ii) a non-init method in the current class, or iii) a non-init method in a superclass of the current class. [Note: does "in" mean "declared in" or "referenced in"?])
- Case (ii) should not be read to exclude the possibility that the "current class" is an interface
- Another case, (iv), is permitted by the structural constraints (4.9.2): a non-init method referenced via a _direct_ superinterface of the current class/interface. (It's not clear to me whether case (iii) is meant to refer to the _named_ class or the _resolved method's_ class. But this, for (iv), must be a restriction on the named class.)
- Selection for case (iv) is just like selection for cases (i) and (ii) -- the resolved method is the selected method.
- Selection for case (iii) needs to search superinterfaces before giving up, much like invokevirtual selection.
(For clarity, I consider the following cases of the invokespecial method. i) an instance initialization method, ii) a non-init method in the current class, or iii) a non-init method in a superclass of the current class. [Note: does "in" mean "declared in" or "referenced in"?])
- Case (ii) should not be read to exclude the possibility that the "current class" is an interface
- Another case, (iv), is permitted by the structural constraints (4.9.2): a non-init method referenced via a _direct_ superinterface of the current class/interface. (It's not clear to me whether case (iii) is meant to refer to the _named_ class or the _resolved method's_ class. But this, for (iv), must be a restriction on the named class.)
- Selection for case (iv) is just like selection for cases (i) and (ii) -- the resolved method is the selected method.
- Selection for case (iii) needs to search superinterfaces before giving up, much like invokevirtual selection.