Class invoking method which exists as default on interface and private on super
Alex Buckley
alex.buckley at oracle.com
Wed Feb 14 00:21:02 UTC 2018
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
More information about the compiler-dev
mailing list