+ +

@EqualsAndHashCode

Equality made easy: Generates hashCode and equals implementations from the fields of your object.

Overview

+ Any class definition may be annotated with @EqualsAndHashCode to let lombok generate implementations of the + equals(Object other) and hashCode() methods. By default, it'll use all non-static, non-transient + fields, but you can exclude more fields by naming them in the optional exclude parameter to the annotation. +

+ By setting callSuper to true, you can include the equals and hashCode methods of your superclass in the generated methods. + For hashCode, the result of super.hashCode() is included in the hash algorithm, and for equals, the generated method will return + false if the super implementation thinks it is not equal to the passed in object. Be aware that not all equals implementations handle this situation properly. + However, lombok-generated equals implementations do handle this situation properly, so you can safely call your superclass equals if it, too, + has a lombok-generated equals method.
+

+ Setting callSuper to true when you don't extend anything (you extend java.lang.Object) is a compile-time error, because it would turn + the generated equals() and hashCode() implementations into having the same behaviour as simply inheriting these methods from java.lang.Object: + only the same object will be equal to each other and will have the same hashCode. Obviously, inheriting java.lang.Object is the right strategy if you want this behaviour. + Not setting callSuper to true when you extend another class generates a warning, because unless the superclass has no (equality-important) fields, lombok + cannot generate an implementation for you that takes into account the fields declared by your superclasses. You'll need to write your own implementations, or rely on the + callSuper chaining facility. +

With Lombok

@HTML_PRE@

Vanilla Java

@HTML_POST@

Small print

+ Arrays are 'deep' compared/hashCoded, which means that arrays that contain themselves will result in StackOverflowErrors. However, + this behaviour is no different from e.g. ArrayList. +

+ You may safely presume that the hashCode implementation used will not change between versions of lombok, however this guarantee is not set in stone; + if there's a significant performance improvement to be gained from using an alternate hash algorithm, that will be substituted in a future version. +

+ For the purposes of equality, 2 NaN (not a number) values for floats and doubles are considered equal, eventhough 'NaN == NaN' would + return false. This is analogous to java.lang.Double's equals method, and is in fact required to ensure that comparing an object + to an exact copy of itself returns true for equality. +

+ If there is any method named either hashCode or equals, regardless of parameters or return type, + that method will not be generated, and a warning is emitted instead. hashCode and equals need to be in sync with + each other, which lombok cannot guarantee if it is only generating one of the two methods, hence you always get a warning if one or both + of the methods already exist. +

+ Attempting to exclude fields that don't exist or would have been excluded anyway (because they are static) results in warnings on the named fields. + You therefore don't have to worry about typos. +

+ +