From f8b3056dc4f61251aba7adf627c942c85e8618ca Mon Sep 17 00:00:00 2001 From: Reinier Zwitserloot Date: Sun, 1 Jun 2014 11:02:18 +0200 Subject: Fixed up and extended Tolerate with support for constructors, and added docs. --- website/features/EqualsAndHashCode.html | 34 ++++++++------------------------- 1 file changed, 8 insertions(+), 26 deletions(-) (limited to 'website/features/EqualsAndHashCode.html') diff --git a/website/features/EqualsAndHashCode.html b/website/features/EqualsAndHashCode.html index 89d71502..32dcb6c3 100644 --- a/website/features/EqualsAndHashCode.html +++ b/website/features/EqualsAndHashCode.html @@ -15,22 +15,11 @@

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. - Alternatively, you can specify exactly which fields you wish to be used by naming them in the of parameter. + 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. Alternatively, you can specify exactly which fields you wish to be used by naming them in the of parameter.

- 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.
+ 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. - 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 + 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. 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.

NEW in Lombok 0.10: Unless your class is final and extends java.lang.Object, lombok generates a canEqual method @@ -66,22 +55,15 @@

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. + 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. + 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. + 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 return type, no methods will be generated, and a warning is emitted instead. These 2 methods need to be in sync with - each other, which lombok cannot guarantee unless it generates all the methods, hence you always get a warning if one or both - of the methods already exist. + If there is any method named either hashCode or equals, regardless of return type, no methods will be generated, and a warning is emitted instead. These 2 methods need to be in sync with each other, which lombok cannot guarantee unless it generates all the methods, hence you always get a warning if one or both of the methods already exist. You can mark any method with @lombok.experimental.Tolerate to hide them from lombok.

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

Having both exclude and of generates a warning; the exclude parameter will be ignored in that case.

-- cgit