On 09/12/2013 03:37 PM, Joel Borggrén-Franck wrote:
Hi again,
New webrev: http://cr.openjdk.java.net/~jfranck/8009411/webrev.01/
Thanks to Remi and Peter for the quick feedback, I've updated the code
to use for-each as well as fixing getMethod(...).
Andreas Lundblad also added ~100 testcases for getMethod(), both
positive and negative.
Please review
cheers
/Joel
Hi Joel,
This looks correct now. I just wonder about the following corner case.
Suppose you have:
public interface A {
default void m() {
}
}
public interface B extends A {
static void m() {
}
}
public interface C extends B {
}
This does not actually compile, and I think this is correct:
/home/peter/work/local/DefaultVsStaticInterfaceMethodCrash/src/B.java
Error:Error:line (2)java: m() in B clashes with m() in A
overriding method is static
But if interface A at first does not have method m(), it compiles. If
later default method m() is added to interface A and A is compiled
separately, then what happens?
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.
Regards, Peter
On 2013-09-09, Joel Borggrén-Franck wrote:
Hi
Pleaser review fix for 8009411 : getMethods should not inherit static methods
from interfaces
The issue is that since we added static methods to interfaces those have
erroneously been reflected in getMethods of implementing classes. This fix
filters out static interface methods from superinterfaces when adding methods.
I have also added a note to the javadoc for both getMembers and
getDeclaredMembers pointing this out (though it is implied from JLS). Webrev is
based on the clarification to getMethods and friends out for review on this
list.
Webrev: http://cr.openjdk.java.net/~jfranck/8009411/webrev.00/
Bug is here: http://bugs.sun.com/view_bug.do?bug_id=8009411
For oracle reviewers, ccc is approved.
cheers
/Joel
