Class invoking method which exists as default on interface and private on super

[Alex Buckley]

On 2/13/2018 3:43 PM, Michael Rasmussen wrote:
>> (I'm assuming the 8.0.5.5 version string indicates an
>> implementation of SE 8.)
> Yes. SE 8.

Good to know, thanks. Of course, no-one from J9 is on this list.

>> - For the invokevirtual, the method to be resolved is Test::foo,
>> and the first matching method found is C::foo, and thus resolution
>> fails because C::foo is inaccessible to Test. Nothing more to say.
>
> A follow-up question to that.
>
> If I change C::foo to be static instead, it still compiles to the
> same (invokeinterface and invokevirtual). When running,
> invokeinterface now calls I::foo, but the invokevirtual tries to call
> the static C::foo, and gets access error because it's private.
> (tested on 10-ea+43)
>
> so the static C::foo is now no longer a valid candidate for
> invokeinterface, but still is for invokevirtual?

Talking about who "calls" who is not precise enough:

- For invokeinterface I::foo, invokeinterface resolves the foo method in 
interface I without issue, then proceeds to select an instance method. 
Thus, invokeinterface skips the static C::foo in the superclass 
hierarchy and moves on to the superinterface hierarchy. This is 
consistent across SE 8/9/10/11 and explained in detail in JVMS ch.6.

- OTOH, for invokevirtual Test::foo, invokevirtual can't even get as far 
as resolving Test::foo. Per JVMS 5.4.3.3, there is no method called foo 
in Test, and the one in C is rejected for inaccessibility.

Alex