Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

An object is characterized by its identity (location in memory) and state (actual data). While the '==' operator compares only the identities of two objects (to check if both the references are actually the same object), the equals method defined in java.lang.Object can compare the state as well, when customized by overriding it.

The equals method only applies to Objectsobjects, not primitives. Also, immutable objects do not need to override equals. There is no need to override equals if checking logical equality is not useful. Enum Enumerated types are an example. If a subclass inherits an implementation of equals from a superclass and does not need additional functionality, one can forgo overriding equals() can be forgone.

Wiki Markup
The general usage contract for {{equals()
. The Java specification
}} as specified by the Java Language Specification \[[JLS 05|AA. Java References#JLS 05]\] says:

  • It is reflexive: For any reference value x, x.equals(x) must return true.
  • It is symmetric: For any reference values x and y, x.equals(y) must return true if and only if y.equals(x) returns true.
  • It is transitive: For any reference values x, y, and z, if x.equals(y) returns true and y.equals(z) returns true, then x.equals(z) must return true.
  • It is consistent: For any 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 object is modified.
  • For any non-null reference value x, x.equals(null) must return false.

Wiki Markup
Do not violate any of these five conditions while overriding the {{equals}} method. Mistakes resulting from a violation of to the first postulatecondition are infrequent; it is consequently omitted from this discussion. The second and third conditions are highlighted. The rule for consistency implies that mutable objects may not satisfy the {{equals}} contract. It is good practice to avoid defining {{equals()}} implementations that use unreliable data sources such as IP addresses \[[Bloch 08|AA. Java References#Bloch 08]\] and caches. The final condition about the comparison with {{null}} is typically violated when the {{equals()}} code throws an exception instead of returning {{false}}. Because this does not constitute a security vulnerability, it is beyond the scope of this discussion.  

...

This noncompliant code example violates transitivity although though it follows satisfies the symmetry condition. This is because In the first two statements print true while the third prints falseprint statement, the comparison between p1 and p2 returns true, in the second, the comparison between p2 and p3 returns false and in the third, the comparison between p1 and p3 returns false. This is counter intuitive as p1 and p2 must compare equal when they are both equal to a common object. A practical implementation issue is intermingling of java.sql.Timestamp and java.util.Date classes. There is a disclaimer about the erratic behavior in the documentation for the Timestamp class.

...

MET03-J. For methods that return an array or collection prefer returning an empty array or collection over a null value      1009. Methods (MET)      MET31-J. Ensure that hashCode() is overridden when equals() is overridden