AutoValue.CopyAnnotations does not apply to equals(Object).

[sebright2]

I am starting to run Checker Framework null analysis on https://github.com/census-instrumentation/opencensus-java. The Checker Framework requires equals to have a Nullable parameter (related to issue #73), so I tried using AutoValue.CopyAnnotations to copy the annotation from an abstract equals method to the generated subclass:

  @Override
  @AutoValue.CopyAnnotations
  public abstract boolean equals(@Nullable Object other);

CopyAnnotations had no effect on the generated equals method, so I instead tried putting a SuppressWarnings annotation on the whole method:

  @Override
  @SuppressWarnings("nullness")
  @AutoValue.CopyAnnotations
  public abstract boolean equals(Object other);

That change also had no effect on the generated method. I expected CopyAnnotations to copy annotations for any method or method parameter, including methods from Object.

[eamonnmcmanus]

The Checker Framework is clearly wrong here and should be fixed. The parameter to equals(Object) can always be null, regardless of its annotations.

I'm not sure I see a compelling reason to support this copying. It's certainly very roundabout: the user has to redeclare the equals method as an abstract method just so that the annotations can be parked there. Are there other examples of annotations that users could want to place on equals or hashCode or toString?

[sebright2]

I think that the Checker Framework assumes that everything is non-null by default and even uses Nullable annotations for the JDK. If I understand correctly, this file specifies the annotations for java.lang.Object: https://github.com/typetools/checker-framework/blob/2e6029fc062304cf4d468b9e5650315f69c268dd/checker/jdk/nullness/src/java/lang/Object.java#L11

[sebright2]

I'm not sure I see a compelling reason to support this copying. It's certainly very roundabout: the user has to redeclare the equals method as an abstract method just so that the annotations can be parked there. Are there other examples of annotations that users could want to place on equals or hashCode or toString?

I can't think of any other examples, besides other annotations for the Checker Framework (It also uses @SideEffectFree and @Pure.) or other types of static analysis.

[eamonnmcmanus]

OK, I'm a little more receptive to the idea now. :-) Since it's quite unusual to redeclare the Object methods as abstract, there probably aren't compatibility concerns about starting to copy annotations on them.

[rkraneis]

Any progress on this? We are running into the same problem. Currently the only work around seems to be adding SuppressWarnings("nullness") on a class level and copying it over or manually implementing equals.

[eamonnmcmanus]

I think we could reasonably copy type annotations from the parameter declaration to its implementation. So if you wrote this...

@AutoValue
abstract class Foo {
  abstract String bar();
  ...
  @Override abstract boolean equals(@Nullable Object x);
}

...then AutoValue_Foo.equals would look like this:

class AutoValue_Foo extends Foo {
  ...
  @Override boolean equals(@Nullable Object x) {
     ...
  }
  ...
}

We would only do this if @Nullable is a TYPE_USE annotation, which the one from the Checker Framework is.

I continue to think that the Checker Framework is being hostile here. The specific case of equals(Object) is surely worth special-casing.

[sebright2]

Does Foo's equals method still need @AutoValue.CopyAnnotations?

[eamonnmcmanus]

No. Type annotations will be copied whether or not @AutoValue.CopyAnnotations is present, and in fact that annotation will have no effect. However, it will still be necessary to write the abstract redeclaration of equals(Object).