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.
I've recently come across a surprising behaviour regarding
MemberResolver
'sgetMemberMethods
. Consider the following classes:Notice that
C
implementsA.doSomething()
throughB.doSomething()
.When inspecting the members of C like this:
methods
will contain a single method -public abstract Foo A.doSomething()
. However, this doesn't tell the whole story - notice thatB.doSomething
actually returns aBar
instead of aFoo
. Therefore, in this case I'd expectmethods
to containpublic Bar B.doSomething()
, which gives me more information thanA.doSomething()
does.