RFR: 8009411 : getMethods should not inherit static methods from interfaces

[Joel Borggrén-Franck]

Hi Peter,

Interesting case, thanks for the testing.

On Sep 13, 2013, at 1:15 PM, Peter Levart <peter.levart at 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