We got caught by an interesting trap using a couple of other transforms recently: @EqualsAndHashCode and @Immutable. We like to use @EqualsAndHashCode to generate equals() and hashCode() for entity classes in our domain model. We use the 'includes' attribute to include only the primary key properties in the equals() comparison, like this:
@EqualsAndHashCode(includes = "id")
class Foo {
String id
String description
}
For this class, and its corresponding database table, the 'id' property is the key. Equality is not done by Java object equality, or by full value equality, but by comparing the entities' primary keys:
assert new Foo(id: "1", description: "cat") ==
new Foo(id: "1", description: "dog")
This has important effects when storing these kinds of objects in collections.Be careful mixing AST transform annotations though! We added @Immutable to some of our domain classes, like this:
@Immutable
@EqualsAndHashCode(includes = "id")
class Foo {
String id
String description
}
and got a surprising result:
assert new Foo(id: "1", description: "cat") !=
new Foo(id: "1", description: "dog")
The reason is the order of the annotations. If we reverse them, it works correctly:
@EqualsAndHashCode(includes = "id")
@Immutable
class Foo {
String id
String description
}
assert new Foo(id: "1", description: "cat") ==
new Foo(id: "1", description: "dog")
So what happens? The doc for @Immutable says:
The @Immutable annotation instructs the compiler to execute an AST transformation which adds the necessary getters, constructors, equals, hashCode and other helper methods that are typically written when creating immutable classes with the defined properties.Later on, in more detail:
Default equals, hashCode and toString methods are provided based on the property values. Though not normally required, you may write your own implementations of these methods. For equals and hashCode, if you do write your own method, it is up to you to obey the general contract for equals methods and supply a corresponding matching hashCode method. [...]So, I'm guessing that if we put @Immutable first, then @EqualsAndHashCode hasn't yet had a chance to do its magic, and @Immutable adds its default equals() etc, not the ones we want. But if we put @EqualsAndHashCode first, then its equals() etc methods are there for @Immutable to see, and we get the behavior we want.
Thus, problem solved, for now. But it does make one wonder a little about the interactions of all of these transforms and other annotations. We've been using Groovy AST transform annotations together with JPA annotations with no known problems to date, and I hope it continues that way.
