Following up on email from a few months ago....

On 12/19/2012 01:01 AM, Peter Levart wrote:
On 12/19/2012 01:35 AM, David Holmes wrote:
On 19/12/2012 10:24 AM, Joe Darcy wrote:
On 12/18/2012 04:20 PM, David Holmes wrote:
On 19/12/2012 10:16 AM, Joe Darcy wrote:
On 12/18/2012 04:12 PM, David Holmes wrote:
On 19/12/2012 8:40 AM, Louis Wasserman wrote:
It's not 100% obvious to me whether this refers to a default
implementation
in an interface, a class which inherits that default implementation
and does not override it, or both. Is that worth clarifying in the doc,
rather than forcing readers to check the JLS citation?

The issue is where you obtained this Method reference from:

- from the Interface? then it is a default method
- from a class implementing the interface but not redefining the
method? then it is a default method

Actually, that is *now* how HotSpot represents this case in core
reflection at the moment. HotSpot uses a new method object to represent
the default method woven into an implementing class.

*now* -> *not* ??

Correct.


It may be a new Method object but getDeclaringClass() should give the
interface class NOT the concrete class. That is currently the case for
abstract interface methods. I hope it is the same for default methods!

It is not at the moment, which is a bit surprising.

Very surprising! I'd call that a major bug.

Not only default methods, also abstract interface methods show-up in the implementing class's declared methods. For example the following test:

public class DefaultMethodsTest {
    public interface I {
        void i();
        default void d() { }
    }

    public abstract static class S {
        public abstract void a();
        public void s() { }
    }

    public abstract static class C extends S implements I {
        public void c() { }
    }

    public static void main(String[] args) {
        for (Method m : C.class.getDeclaredMethods())
            System.out.println(m.getName());
    }
}


prints:

c
i
d

As of build 84 of JDK 8, this behavior has been corrected by the fix for

JDK-8010017 lambda: reflection get(Declared)Methods support for concrete methods in interfaces

The test program above will now just print
c

Test cases similar to the program above were subsequently pushed into the JDK repo under

    JDK-8011590 More tests for core reflection modeling of default methods

Cheers,

-Joe

Reply via email to