From 728ae6421dd03bc78e37c0eb5d860f932b5fff2c Mon Sep 17 00:00:00 2001 From: Reinier Zwitserloot Date: Mon, 23 Nov 2015 03:12:50 +0100 Subject: [Fixes #965] Adds a config key to automatically determine the behaviour of equals and hashCode generation when --- website/features/EqualsAndHashCode.html | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'website/features/EqualsAndHashCode.html') diff --git a/website/features/EqualsAndHashCode.html b/website/features/EqualsAndHashCode.html index b220e955..ab43fd5a 100644 --- a/website/features/EqualsAndHashCode.html +++ b/website/features/EqualsAndHashCode.html @@ -21,7 +21,7 @@ this code will not be generated. 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. If you have an explicit superclass you are forced to supply some value for callSuper to acknowledge that you've considered it; failure to do so results in a warning.

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. + callSuper chaining facility. You can also use the lombok.equalsAndHashCode.callSuper config key.

NEW in Lombok 0.10: Unless your class is final and extends java.lang.Object, lombok generates a canEqual method which means JPA proxies can still be equal to their base class, but subclasses that add new state don't break the equals contract. The complicated reasons for @@ -49,6 +49,8 @@

lombok.equalsAndHashCode.doNotUseGetters = [true | false] (default: false)
If set to true, lombok will access fields directly instead of using getters (if available) when generating equals and hashCode methods. The annotation parameter 'doNotUseGetters', if explicitly specified, takes precedence over this setting.
+
lombok.equalsAndHashCode.callSuper = [call | skip | warn] (default: warn)
+
If set to call, lombok will generate calls to the superclass implementation of hashCode and equals if your class extends something. If set to skip no such calls are generated. The default behaviour is like skip, with an additional warning.
lombok.equalsAndHashCode.flagUsage = [warning | error] (default: not set)
Lombok will flag any usage of @EqualsAndHashCode as a warning or error if configured.
-- cgit