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

[Peter Levart]

On 09/13/2013 02:55 PM, Joel Borggrén-Franck wrote:
> 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 :)

It is non-trivial to arrange in a unit test. See the following for one 
possible trick:

http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.05/test/java/lang/annotation/AnnotationType/AnnotationTypeRuntimeAssumptionTest.java.html

It's expectable that such situations will arise in practice. interface A 
can be a part of a vendor X library that's adding default methods in a 
new release, for example, and B & C can be part of a vendor Y app that 
is using the library...

Regards, Peter

>
> 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