![JAR search and dependency download from the Maven repository](/logo.png)
errorprone.bugpattern.NonOverridingEquals.md Maven / Gradle / Ivy
The newest version!
Defining a method that looks like `Object#equals` but doesn't actually override
`Object#equals` is dangerous. The result of the comparison could differ
depending on the declared type of the argument passed into the `equals` call.
For example, consider this code:
```java
public class Example {
private int value;
public Example(int value) {
this.value = value;
}
public boolean equals(Example other) {
return this.value == other.value;
}
public static void main(String[] args) {
Example exampleA = new Example(1);
Example exampleB = new Example(1);
System.out.println(exampleA.equals(exampleB));
}
}
```
This will print `true`. Suppose you refactor it so that the variable `exampleB`
is declared as an `Object` instead. Now this code will print `false`, because
Java's overload resolution will choose the default `equals(Object)`
implementation instead of the `equals(Example)` method defined in this class.
If this equals method is intended to be a type-specific helper for an `equals`
method that *does* override `Object#equals`, either inline it into the
overriding `equals` method or rename it to something other than `equals` to
avoid ambiguity in overload resolution.
If you don't want to write and maintain `equals` and `hashCode` methods by hand,
consider rewriting this class to use
[AutoValue](https://github.com/google/auto/tree/master/value).
© 2015 - 2025 Weber Informatics LLC | Privacy Policy