Best practices regarding equals: to overload or not to overload?

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.

If you have one single field as in your example, I think

@Override public boolean equals(Object o) {
    return (o instanceof Thing) && (this.x == ((Thing) o).x);
}

is the way to go. Anything else would be overly complicated imo. But if you add a field (and don't want to pass the 80-column recommendation by sun) it would look something like

@Override public boolean equals(Object o) {
    if (!(o instanceof Thing))
        return false;
    Thing t = (Thing) o;
    return this.x == t.x && this.y == t.y;
}

which I think is slightly uglier than

public boolean equals(Thing o) {
    return this.x == o.x && this.y == o.y;
}

@Override public boolean equals(Object o) {
    // note that you don't need this.equals().
    return (o instanceof Thing) && equals((Thing) o);
}

So my rule of thumb is basically, if need to cast it more than once in override-only, do the override-/overload-combo.

---

A secondary aspect is the runtime overhead. As Java performance programming, Part 2: The cost of casting explains:

Downcast operations (also called narrowing conversions in the Java Language Specification) convert an ancestor class reference to a subclass reference. This casting operation creates execution overhead, since Java requires that the cast be checked at runtime to make sure that it's valid.

By using the overload-/override-combo, the compiler will, in some cases (not all!) manage to do without the downcast.

---

To comment on @Snehal point, that exposing both methods possibly confuses client-side developers: Another option would be to let the overloaded equals be private. The elegance is preserved, the method can be used internally, while the interface to the client side looks as expected.

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