MoreElements.getLocalAndInheritedMethods or alternative should resolve type parameters if applicable

[victornoel]

I have the following class hierarchy:

public interface ASuperInterface<A> {
  void test(A a);
}

public interface AnInterface extends ASuperInterface<String> {
  void test();
}

Calling MoreElements.getLocalAndInheritedMethods on the element representing AnInterface gives me a method void test(A a) instead of a method void test(String a).

If this is intended and there is no other recommended way to resolve type parameters like this, I think auto-common should include an helper to do so.

[eamonnmcmanus]

The main problem is that the Eclipse compiler has never implemented Types.asMemberOf correctly. Some bugs have been fixed (382590 and 510118) but some remain (499026). That makes it hard to address otherwise reasonable requests like this, without throwing Eclipse users under the bus.

[victornoel]

@eamonnmcmanus good point, thanks for the explanation.
By the way, don't you have the need in one of the Auto annotation processor or do you handle this problem in a different way than with Types.asMemberOf?

For the record, as a workaround, I tackled this problem during code generation. I am using javapoet and they have MethodSpec.overriding() taking the containing type and making some use of Types.asMemberOf to achieve the desired result. I suppose this mean MethodSpec behaviour is also touched by the Eclipse bugs, but it's better than nothing for my needs :)

[eamonnmcmanus]

I'm still not really sure what the best solution is here. For the record, if you're not afraid of the Eclipse bug, you should be able to replace the type parameters yourself in this somewhat non-obvious way:

ExecutableElement originalMethod = ...;
Types types = processingEnv.getTypeUtils();
ExecutableElement replacedMethod =
    MoreElements.asExecutable(types.asMemberOf(someType, originalMethod));

Yes, we do run into this issue in AutoValue and we work around it as best we can.

[victornoel]

@eamonnmcmanus yes, I did something like (but via javapoet).

Yes, we do run into this issue in AutoValue and we work around it as best we can.

Could you point me to where in the codebase this happen maybe?

[eamonnmcmanus]

The main place is in EclipseHack.

[victornoel]

@eamonnmcmanus thanks, and why not expose this behaviour in auto common? I'm sure it will be useful to many :)