JDK-8024806 : invokeinterface: Remove IAE for selection of non-public method
  • Type: Enhancement
  • Component: specification
  • Sub-Component: vm
  • Affected Version: 7,8
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2013-09-13
  • Updated: 2018-01-17
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
Blocks :  
JDK-8021581 - Private class methods interfere with invocations of interface methods
Relates :  
JDK-8177020 - Nestmates JVMS changes
Relates :  
JDK-8024808 - Lambda Spec: specify skipping of private methods during invokevirtual selection
Relates :  
JDK-8098577 - 6.5: invokevirtual must specify selection when resolved method is in interface
Description
invokeinterface requires an IAE if the selected method is not public.

invokevirtual performs no checks on the access of the selected method (although it skips over private methods).

This distinction is unnecessary and arbitrary.  It would probably be better to simply eliminate the access check for invokeinterface (and also change its behavior so that it skips private methods).

The change would be fully compatible: it eliminates an error.
Comments
JDK-8177020 addresses the private case, but due to concerns outlined above, keeps the check in place for protected and package methods. Next step: JDK-8021581 intends to address mismatches between the intended inheritance behavior and resolution/selection. With such a fix, we may be able to eliminate the invokeinterface restriction entirely.
17-01-2018
It is accurate to say that the change is a compatible one, by relaxing constraints on programs that would otherwise fail. It is also true that relaxing this constraint opens up unwanted possibilities: namely, that anyone who can extend a class can gain access to its protected and package members. (Protected members are already "accessible" to subclasses, but there are additional restrictions that wouldn't be enforced if they were selected via invokeinterface.) Say a sensitive method m is declared in C. My argument that invokevirtual already provides a back door for accessing m���"someone with access to a superclass can introduce a method to get to the behavior of the subclasses' non-public methods"���failed to distinguish between changes to a superclass of C and changes to an unrelated interface I. Presumably C trusts its superclasses not to expose its members. But C can't necessarily trust its subclasses and the interfaces they implement.
17-01-2018
> "The change would be fully compatible: it eliminates an error. " That is a mis-characterisation IMHO. This change allows code to invoke a method that should be inaccessible to it. I would strongly argue that the invokevirtual behaviour is inappropriate and in fact surprising. While we may be stuck forever with the invokevirtual behaviour it should not be a justification for changing the invokeinterface behavuiour - two wrongs do not make a right.
21-12-2017
Update: In JDK8, the JVMS was modified so that invokeinterface throws ICCE if the selected method is private. It still throws IllegalAccessError if the selected method found in a class is not public. In JDK-6810795 (Alex, Vladimir I, Tony Printezis and I) decided to not check selection time access for invokevirtual due to backward compatibility. So invokevirtual, someone with access to a superclass can introduce a method to get to the behavior of the subclasses' NON-PRIVATE methods. Private methods are not involved in the overriding rules for invokevirtual.
21-11-2017
Note that this implies someone with access to a superinterface can introduce a method that will provide access to the behavior of implementing classes' non-public methods. However, invokevirtual is similar: someone with access to a superclass can introduce a method to get to the behavior of the subclasses' non-public methods.
12-11-2013