From 3c47eb1299467f052f25581430d20bc3b2b83f4d Mon Sep 17 00:00:00 2001 From: Reinier Zwitserloot Date: Thu, 18 Nov 2010 12:45:02 +0100 Subject: Added documentation for val and @Getter(lazy=true) and updated docs for Log and EqualsAndHashCode to reflect new lombok 0.10 features. --- website/features/EqualsAndHashCode.html | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'website/features/EqualsAndHashCode.html') diff --git a/website/features/EqualsAndHashCode.html b/website/features/EqualsAndHashCode.html index c5128d10..dbe45218 100644 --- a/website/features/EqualsAndHashCode.html +++ b/website/features/EqualsAndHashCode.html @@ -28,10 +28,16 @@

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. + 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 + 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 + why such a method is necessary are explained in this paper: (TODO: Find link to Venners/Spoon/Odersky). If all classes in a hierarchy are a mix of scala case classes + and classes with lombok-generated equals methods, all equality will 'just work'. If you need to write your own equals methods, you should always override canEqual + if you change equals and hashCode.

-- cgit