Hi Peter,
Interesting case, thanks for the testing.
On Sep 13, 2013, at 1:15 PM, Peter Levart <peter.lev...@gmail.com> wrote:
> On 09/13/2013 12:18 PM, Peter Levart wrote:
>> The C.class.getMethods() returns a 1 element array containing A.m(), but
>> C.class.getMethod("m") throws NoSuchMethodException.
>>
>> This seems inconsistent, but it's a corner case that can only happen with
>> separate compilation.
>
> Sorry Joel, I must have tested the unpatched code for C.class.getMethods().
> In is in fact consistent with C.calss.getMethod("m"). Both calls don't return
> the A.m() method. in getMethod("m") case the recursion is stoped when B.m()
> static method is encountered and in getMethods() case the inherited method
> A.m() is removed from inheritedMethods array by the following in
> privateGetPublicMethods():
>
> // Filter out all local methods from inherited ones
> for (int i = 0; i < methods.length(); i++) {
> Method m = methods.get(i);
> inheritedMethods.removeByNameAndSignature(m);
> }
>
> ...when collecting B's methods...
>
> But the question remains whether A.m() should be seen by invokeinterface
> C.m() in spite of the fact that there is static B.m() in between and whether
> reflection should follow that.
I can't see any reason why an invokeinterface C.m() should not find a default
method just because there is a static method with the same name and sig "in
between". However the separate compilation setup required to arrange this is
non-trivial in itself :)
I also believe that reflection should accommodate separate compilation to the
best extent possible. In this case I would prefer if A.m() were found and I
think the fix in both reasonably small and without compatibility concerns since
this is new territory.
cheers
/Joel
