Eclipse compiler re-orders properties when defined in multiple interfaces.

[JakeWharton]

Given the following source inside Eclipse:

interface Thing {
  String one();
  String two();
  boolean three();
  long four();
}
interface Other {
  String two();
  long four();
}
@com.google.auto.value.AutoValue
abstract class Impl implements Thing, Other {
}

with auto-value-1.3.jar added to the compilation and processor classpath, Eclipse generates .apt_generated/AutoValue_Impl.java which looks like this (abridged):

 final class AutoValue_Impl extends Impl {

  private final String one;
  private final boolean three;
  private final String two;
  private final long four;

  AutoValue_Impl(
      String one,
      boolean three,
      String two,
      long four) {

As you can see the order from the first interface is retained except for properties that were also defined in the second interface which were hoisted to the end of the list.

This reflects Eclipse bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=500570 which was identified using Android's Jack compiler (built on ecj) http://b.android.com/219927. Oracle's JDK and OpenJDK javac do not exhibit this behavior and instead supply the annotation processor with the four properties in the order of the first interface only.

[JakeWharton]

Forgot to mention this was Eclipse Neon 4.6.0 and JDK 1.8.0_102.

[eamonnmcmanus]

I don't think we clearly document what happens in cases like these, but it plainly needs to be deterministic and consistent across compilers. The relevant code is in MoreElements and from other conversations I believe it is running into a difference in the behaviour of Elements.overrides.

[jbgi]

For what it is worth, here is the strategy I adopted in derive4J to get predictable order across ecj/javac:

1. retrieve all abstract methods (unordered) via Elements#getAllMembers.
2. de-duplicate the methods via Types#isSubsignature (after conversion to ExecutableType via Types#asMemberOf).
3. Reorder the methods obtained in 2. via a predictable walk up the class/interface hierarchies, using TypeElement#getEnclosedElements on each class/interface: TypeElement#getEnclosedElements is now guaranteed to return elements in the source order (the bug in ecj on this one has been fixed).

(for some unknown reason I did not succeed to de-duplicate directly starting from the methods founds via 3. but I may have done an error in my code).

[eamonnmcmanus]

Thanks @jbgi, that's very interesting!

I think we are in a situation where we have to preserve the existing order, determined by MoreElements using javac's javax.lang.model.util.Elements. If we changed any detail of that order we would break a lot of existing code. (I know this for a fact based on Google's internal usages.) The approach I've been working on is to reimplement Elements.overrides using other methods from Elements and Types. That way we're no longer affected by inconsistencies between the javac and ecj versions of overrides.

My impression from this reimplementation is that there is at least one case where javac's decisions are not strictly equivalent to what the JLS says. I think there's an extra rule beyond the ones spelled out in "An instance method m_C declared in or inherited by class C, overrides from C another method m_I declared in an interface I" in 8.4.8.1. Namely, javac doesn't consider that an inherited abstract method can override an interface method.

By spelling out the override logic rather than relying on Elements.override, we should be able to preserve the ordering between the two compilers and also future-proof against changes to what Elements.override does.

I hadn't thought of using Types.isSubsignature and I think that might improve my code.