Unintuitive information about member methods wrt return type covariance

[zdenek-biberle]

I've recently come across a surprising behaviour regarding MemberResolver's getMemberMethods. Consider the following classes:

interface Foo {}

class Bar implements Foo {}

interface A {
    Foo doSomething();
}

class B {
    public Bar doSomething() {
        return null;
    }
}

class C extends B implements A {}

Notice that C implements A.doSomething() through B.doSomething().

When inspecting the members of C like this:

var typeResolver = new TypeResolver();
var methods = new MemberResolver(typeResolver).resolve(typeResolver.resolve(C.class), null, null).getMemberMethods();

methods will contain a single method - public abstract Foo A.doSomething(). However, this doesn't tell the whole story - notice that B.doSomething actually returns a Bar instead of a Foo. Therefore, in this case I'd expect methods to contain public Bar B.doSomething(), which gives me more information than A.doSomething() does.

[cowtowncoder]

@zdenek-biberle I agree, it would seem to me that the declaration from B should have precedence here.