Consider the following snippet:
import java.util.*;
public class EqualsOverload {
public static void main(String[] args) {
class Thing {
There are a number of items in the book that cover this. (It's not in front of me, so I'll refer to items as I remember them)
There is en example exactly using equals(..)
where it is said that overloading should not be used, and if used - it should be used with care. The item about method design warns against overloading methods with the same number of arguments. So - no, don't overload equals(..)
Update: From "Effective Java" (p.44)
It is acceptable to provide such a "strongly typed" equals method in addition to the normal one as long as the two methods return the same result, but there is no compelling reason to do so.
So, it is not forbidden to do so, but it adds complexity to your class, while adding no gains.
As this question is 10 years old and the original author is probably not interested in the answer anymore, I'll add some information that can be useful to developers looking for an answer nowadays.
For Android developers, Android Studio contains a template that will pop-up when trying to overload the equal operator. It also generates a proper hashCode method, and the resulting overridden equals
method would look like this:
@Override
public boolean equals(Object o) {
if (this == o) return true;
if (o == null || getClass() != o.getClass()) return false;
Thing thing = (Thing) o;
return x.equals(thing.x);
}
I use this approach with override and overload combo in my projects, because code looks a bit cleaner. I didn't have problems with this approach so far.
I'dont see the case for overloading equals, except that is more error-prone and harder to maintain, especially when using inheritance.
Here, it can be extremly hard to maintain reflexivity, symmetry and transitivity or to detect their inconsistencies, because you always must be aware of the actual equals method that gets invoked. Just think of a large inheritance hierarchie and only some of the types implementing their own overloading method.
So I'd say just don't do it.
I can think of a very simple example where this won't work properly and why you should never do this:
class A {
private int x;
public A(int x) {
this.x = x;
}
public boolean equals(A other) {
return this.x == other.x;
}
@Override
public boolean equals(Object other) {
return (other instanceof A) && equals((A) other);
}
}
class B extends A{
private int y;
public B(int x, int y) {
super(x);
this.y = y;
}
public boolean equals(B other) {
return this.equals((A)other) && this.y == other.y;
}
@Override
public boolean equals(Object other) {
return (other instanceof B) && equals((B) other);
}
}
public class Test {
public static void main(String[] args) {
A a = new B(1,1);
B b1 = new B(1,1);
B b2 = new B(1,2);
// This obviously returns false
System.out.println(b1.equals(b2));
// What should this return? true!
System.out.println(a.equals(b2));
// And this? Also true!
System.out.println(b2.equals(a));
}
}
In this test, you can clearly see that the overloaded method does more harm than good when using inheritance. In both wrong cases the more generic equals(A a)
is called, because the Java compiler only knows that a
is of type A
and that object does not have the overloaded equals(B b)
method.
Afterthought: making the overloaded equals
private does solve this problem, but was does that really gain you? It only adds an extra method, which can only be called by doing a cast.
Issues with Overloaded Equals:
All the Collections provided by Java ie; Set, List, Map use the overridden method for comparing two objects. So even if you overload the equals method, it doesn't solve the purpose of comparing two objects. Also, if you just overload and implement the hashcode method, it would result in erroneous behavior
If you have both overloaded and overridden equals methods and exposing both these methods you are going to confuse the client side developers. It is by convention people believe that you are overriding the Object class