Are there any scenarios where `==` is true but `equals` is false?

Question

In the Standard Java API, are there any scenarios where == will return true, but equals will return false. While theoretically this could be written into a user-defined class rather trivially like this

class A {
    public boolean equals(Object o) {
        return this != o;
    }
}

Are there any actually baked in examples where for some objects b and c, b == c will return true, but b.equals(c) returns false? Additionally, would there be any possible benefit to have such a behavior?

Answer 1

No*.

The contract for equals has 5 rules, and the first one covers this case:

The equals method implements an equivalence relation on non-null object references:

• It is reflexive: for any non-null reference value x, x.equals(x) should return true.
• It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true.
• It is transitive: for any non-null reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) should return true.
• It is consistent: for any non-null reference values x and y, multiple invocations of x.equals(y) consistently return true or consistently return false, provided no information used in equals comparisons on the objects is modified.
• For any non-null reference value x, x.equals(null) should return false.

Any object in the Java standard library that violates reflexivity would be a bug, and if you do discover such an object in the API, report it to Oracle.

*Less can be said for third-party libraries. Developers make mistakes or are ignorant of the equals contract. Generally this also qualifies as a bug in a third-party library, but YMMV.

Answer 2

In the Standard Java API, are there any scenarios where == will return true, but equals will return false[?]

Not as far as I am aware, and I am confident that any examples you discovered would be considered bugs.

In particular, if x and y are references such that x == y, then it must be the case that x.equals(y) evaluates to the same result as x.equals(x). The contract for Object.equals() (in its docs) says this, in part:

The equals method implements an equivalence relation on non-null object references:

• It is reflexive: for any non-null reference value x, x.equals(x) should return true.

Thus any override of Object.equals() is semantically incorrect if it produces, for any references x and y, the result that x == y && !x.equals(y) is true.

Answer 3

In the Standard Java API, are there any scenarios where == will return true, but equals will return false.

I'm not sure if this is exactly what you have in mind, but implementations of equals are not required to be threadsafe, and are not required to explicitly check if the argument is the same instance as this. So it's quite possible, in principle, for foo.equals(foo) to return false if foo is simultaneously being modified in another thread.

I doubt any JDK class is explicitly documented as not including this check; rather, that's considered an implementation detail, except for classes where that is the only check. But I've managed to get sb.equals(sb) to at least raise an ArrayIndexOutOfBoundsException when sb is a StringBuilder to which another thread is busily adding elements; so if you're particularly unlucky in your timing, it should also be capable of returning false.

Additionally, would there be any possible benefit to have such a behavior?

I really don't think so. The whole purpose of equals is to support things like Set and Map and Assert.assertEquals and so on. There are plenty of use-cases that don't use equals at all, but I can't imagine a non-terrible piece of code that does use equals but wants it to not denote a form of equality that's satisfied by identity.

That said, it's certainly possible for a non-terrible piece of code to have a bug that accidentally causes this. For example, I mentioned in a comment above that java.util.Date and java.sql.Timestamp have a design mistake (now officially codified) whereby date.equals(ts) can be true but ts.equals(date) is false. Someone trying to address this sort of issue might modify java.util.Date to include a check if (that.getClass() == Date.class); but then this would result in a non-reflexive equals implementation in any subclass that didn't explicitly override the parent implementation. (Of course, I wouldn't expect such a mistake in the JDK.)

Writing equals correctly in the face of inheritance is actually rather tricky, but fortunately there's a known solution that addresses all the intricacies in a simple way: http://www.artima.com/lejava/articles/equality.html.

Answer 4

As you pointed out, it is certainly possible to implement equals such that x == x but !x.equals(x). However, doing so would violate the documentated behavior of equals, which states that this property must hold for any valid implementation. So you won't find any examples in the Java standard API that do this (unless there's a bug somewhere), and you'll find plenty of code that relies implicitly or explicitly on equals not behaving this way.