RFR: 8272564: Incorrect attribution of method invocations of Object methods on interfaces [v3]

[Maurizio Cimadamore]

On Thu, 9 Sep 2021 11:14:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Consider these declarations:
>> 
>>     interface I {
>>         public String toString();
>>     }
>>     interface J extends I {}
>> 
>> 
>> There are two issues with the `toString` inherited from `I` into `J`:
>> -`Trees.isAccessible(..., I.toString, J)` will return false, because `Resolve.isAccessible` will return false, because `Resolve.notOverriddenIn` returns false, because the `Object.toString` method is found as an implementation of `I.toString` in the context of `J`. This is unfortunate, because `Elements.getAllMembers(J)` will return `I.toString` as a member, not `Object.toString`, so any API client listing all members and then validating them using `Trees.isAccessible` will filter `toString` out. The proposed solution is to avoid using the methods from `java.lang.Object` as implementations of interface methods in `Resolve.notOverriddenIn`. (Interfaces don't inherit from `j.l.Object` per my understanding of JLS.)
>> -as a slightly less problematic case, consider:
>> 
>> I i = null;
>> i.toString(); //AST and classfile contain call to I.toString()
>> J j = null;
>> j.toString(); //AST and classfile contain call to j.l.Object.toString()
>> 
>> 
>> I believe the second invocation should also preferably be a call to `I.toString()`, not a call to `j.l.Object.toString()`. The reason for this behavior is that in javac, interfaces have `j.l.Object` as a supertype, so method lookups over interfaces will look into `j.l.Object` before looking into the superinterfaces, and the concrete method will prevail over the super interface method found later. The proposal is, for interfaces, to only look into `j.l.Object` is a method is not found in the interface and its superinterfaces.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments.

I think we can go ahead for now. Thanks.

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5165