aboutsummaryrefslogtreecommitdiff
path: root/website/templates/features/EqualsAndHashCode.html
diff options
context:
space:
mode:
Diffstat (limited to 'website/templates/features/EqualsAndHashCode.html')
-rw-r--r--website/templates/features/EqualsAndHashCode.html10
1 files changed, 6 insertions, 4 deletions
diff --git a/website/templates/features/EqualsAndHashCode.html b/website/templates/features/EqualsAndHashCode.html
index 3c11367f..5a7b8166 100644
--- a/website/templates/features/EqualsAndHashCode.html
+++ b/website/templates/features/EqualsAndHashCode.html
@@ -3,7 +3,7 @@
<@f.scaffold title="@EqualsAndHashCode" logline="Equality made easy: Generates <code>hashCode</code> and <code>equals</code> implementations from the fields of your object.">
<@f.overview>
<p>
- Any class definition may be annotated with <code>@EqualsAndHashCode</code> to let lombok generate implementations of the <code>equals(Object other)</code> and <code>hashCode()</code> methods. By default, it'll use all non-static, non-transient fields, but you can exclude more fields by naming them in the optional <code>exclude</code> parameter to the annotation. Alternatively, you can specify exactly which fields you wish to be used by naming them in the <code>of</code> parameter.
+ Any class definition may be annotated with <code>@EqualsAndHashCode</code> to let lombok generate implementations of the <code>equals(Object other)</code> and <code>hashCode()</code> methods. By default, it'll use all non-static, non-transient fields, but you can modify which fields are used (and even specify that the output of various methods is to be used) by marking type members with <code>@EqualsAndHashCode.Include</code> or <code>@EqualsAndHashCode.Exclude</code>. Alternatively, you can specify exactly which fields or methods you wish to be used by marking them with <code>@EqualsAndHashCode.Include</code> and using <code>@EqualsAndHashCode(onlyExplicitlyIncluded = true)</code>.
</p><p>
If applying <code>@EqualsAndHashCode</code> to a class that extends another, this feature gets a bit trickier. Normally, auto-generating an <code>equals</code> and <code>hashCode</code> method for such classes is a bad idea, as the superclass also defines fields, which also need equals/hashCode code but this code will not be generated. By setting <code>callSuper</code> to <em>true</em>, you can include the <code>equals</code> and <code>hashCode</code> methods of your superclass in the generated methods. For <code>hashCode</code>, the result of <code>super.hashCode()</code> is included in the hash algorithm, and for<code>equals</code>, 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 <code>equals</code> implementations handle this situation properly. However, lombok-generated <code>equals</code> implementations <strong>do</strong> handle this situation properly, so you can safely call your superclass equals if it, too, has a lombok-generated <code>equals</code> method. If you have an explicit superclass you are forced to supply some value for <code>callSuper</code> to acknowledge that you've considered it; failure to do so results in a warning.
</p><p>
@@ -43,11 +43,13 @@
</p><p>
If there is <em>any</em> method named either <code>hashCode</code> or <code>equals</code>, 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 <em>or</em> both of the methods already exist. You can mark any method with <code>@lombok.experimental.Tolerate</code> to hide them from lombok.
</p><p>
- 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.
</p><p>
- Having both <code>exclude</code> and <code>of</code> generates a warning; the <code>exclude</code> parameter will be ignored in that case.
+ If a method is marked for inclusion and it has the same name as a field, it replaces the field (the method is included, the field is excluded).
</p><p>
- By default, any variables that start with a $ symbol are excluded automatically. You can onlyinclude them by using the 'of' parameter.
+ Prior to lombok 1.16.22, inclusion/exclusion could be done with the <code>of</code> and <code>exclude</code> parameters of the <code>@EqualsAndHashCode</code> annotation. This old-style inclusion mechanism is still supported but will be deprecated in the future.
+ </p><p>
+ By default, any variables that start with a $ symbol are excluded automatically. You can only include them by marking them with <code>@EqualsAndHashCode.Include</code>.
</p><p>
If a getter exists for a field to be included, it is called instead of using a direct field reference. This behaviour can be suppressed:<br />
<code>@EqualsAndHashCode(doNotUseGetters = true)</code>