CodeGen mistakes equals/hashcode on inner classes for manually generated implementations

[ashleyheath]

Example class:

@BeanDefinition
public final class Example implements ImmutableBean {

  @PropertyDefinition(validate = "notNull")
  private final String exampleProperty;

  private static class ExampleInner {

    private final String innerProperty;

    private ExampleInner(String innerProperty) {
      this.innerProperty = innerProperty;
    }

    @Override
    public boolean equals(Object o) {
      if (this == o) {
        return true;
      }
      if (o == null || getClass() != o.getClass()) {
        return false;
      }
      ExampleInner that = (ExampleInner) o;
      return Objects.equals(innerProperty, that.innerProperty);
    }

    @Override
    public int hashCode() {
      return Objects.hash(innerProperty);
    }
  }
}

JodaBean's code gen spots the implementations of equals and hashcode on ExampleInner and decides to omit generating implementations itself (line 617, in org.joda.beans.gen.BeanParser from the looks of things).

Given the code gen doesn't have a true understanding of class structure perhaps an additional flag on the @BeanDefinition could provide an override of the heuristic being applied?

Can simply work around the issue for now by extracting the inner class into its own file but raising this issue for visibility.

[jodastephen]

This is good spot, but probably quite tricky to fix given it would require a lot more knowledge about the class structure.