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.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
:)
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
