Wiki Markup |
---|
Composition or inheritance may be used to create a new class that both encapsulates an existing class and adds one or more fields. When a subclass extends another in this way, the concept of equality for the subclass may or may not involve its new fields. That is, when comparing two subclass objects for equality, sometimes their respective fields must also be equal, and other times they need not be equal. Depending on the concept of equality for the subclass, the subclass might override {{equals()}}. Furthermore, this method must follow the general contract for {{equals()}} as specified by the Java Language Specification \[[JLS 2005|AA. Bibliography#JLS 05]\]. |
An object is characterized both by its identity (location in memory) and by its state (actual data). The ==
operator compares only the identities of two objects (to check whether the references refer to the same object); the equals
method defined in java.lang.Object
can be overridden to compare the state as well. When a class defines an equals()
method, it implies that the method compares state. When the class lacks a customized equals()
method (either locally declared, or inherited from a parent class), it uses the default Object.equals()
implementation that is inherited from Object
. The default Object.equals()
implementation compares only the references and may produce unexpected results.
The equals()
method applies only to objects, not primitives.
Enumerated types have a fixed set of distinct values that may be compared using ==
rather than the equals()
method. Note that enumerated types provide an equals()
implementation that uses ==
internally; this default cannot be overridden. More generally, subclasses that both inherit an implementation of equals()
from a superclass and also lack a requirement for additional functionality need not override the equals()
method.
The general usage contract for equals()
as specified by the Java Language Specification establishes five requirements:
- It is reflexive: For any reference value
x
,x.equals(x)
must returntrue
. - It is symmetric: For any reference values
x
andy
,x.equals(y)
must returntrue
if and only ify.equals(x)
returnstrue
. - It is transitive: For any reference values
x
,y
, andz
, ifx.equals(y)
returnstrue
andy.equals(z)
returnstrue
, thenx.equals(z)
must returntrue
. - It is consistent: For any reference values
x
andy
, multiple invocations ofx.equals(y)
consistently returntrue
or consistently returnfalse
, provided no information used inequals
comparisons on the object is modified. - For any non-null reference value
x
,x.equals(null)
must returnfalse
.
Never violate any of these requirements when overriding the equals()
method.
Noncompliant Code Example (Symmetry)
This noncompliant code example defines a CaseInsensitiveString
class that includes a String
and overrides the equals()
method. The CaseInsensitiveString
class knows about ordinary strings but the String
class has no knowledge of case-insensitive strings. Consequently, CaseInsensitiveString.equals()
method should not attempt to interoperate with objects of the String
class.
Code Block | ||
---|---|---|
| ||
public final class CaseInsensitiveString { private String s; public CaseInsensitiveString(String s) { if (s == null) { throw new NullPointerException(); } this.s = s; } // This method violates symmetry public boolean equals(Object o) { if (o instanceof CaseInsensitiveString) { return s.equalsIgnoreCase(((CaseInsensitiveString)o).s); } if (o instanceof String) { return s.equalsIgnoreCase((String)o); } return false; } public static void main(String[] args) { CaseInsensitiveString cis = new CaseInsensitiveString("Java"); String s = "java"; System.out.println(cis.equals(s)); // Returns true System.out.println(s.equals(cis)); // Returns false } } |
By operating on String
objects, the CaseInsensitiveString.equals()
method violates the second contract requirement (symmetry). Because of the asymmetry, given a String
object s
and a CaseInsensitiveString
object cis
that differ only in case, cis.equals(s))
returns true
while s.equals(cis)
returns false
.
Note that this code also violates MET13-J. Classes that define an equals() method must also define a hashCode() method.
Compliant Solution
In this compliant solution, the CaseInsensitiveString.equals()
method is simplified to operate only on instances of the CaseInsensitiveString
class, consequently preserving symmetry. The class also defines a hashCode()
method.
Code Block | ||
---|---|---|
| ||
public final class CaseInsensitiveString { private String s; public CaseInsensitiveString(String s) { if (s == null) { throw new NullPointerException(); } this.s = s; } public boolean equals(Object o) { return o instanceof CaseInsensitiveString && ((CaseInsensitiveString)o).s.equalsIgnoreCase(s); } public int hashCode() { // ... } public static void main(String[] args) { CaseInsensitiveString cis = new CaseInsensitiveString("Java"); String s = "java"; System.out.println(cis.equals(s)); // Returns false now System.out.println(s.equals(cis)); // Returns false now } } |
Noncompliant Code Example (Transitivity)
This noncompliant code example defines an XCard
class that extends the Card
class.
Code Block | ||
---|---|---|
| ||
public class Card { private final int number; public Card(int number) { this.number = number; } public boolean equals(Object o) { if (!(o instanceof Card)) { return false; } Card c = (Card)o; return c.number == number; } } class XCard extends Card { private String type; public XCard(int number, String type) { super(number); this.type = type; } public boolean equals(Object o) { if (!(o instanceof Card)) { return false; } // Normal Card, do not compare type if (!(o instanceof XCard)) { return o.equals(this); } // It is an XCard, compare type as well XCard xc = (XCard)o; return super.equals(o) && xc.type == type; } public static void main(String[] args) { XCard p1 = new XCard(1, "type1"); Card p2 = new Card(1); XCard p3 = new XCard(1, "type2"); System.out.println(p1.equals(p2)); // Returns true System.out.println(p2.equals(p3)); // Returns true System.out.println(p1.equals(p3)); // Returns false, violating transitivity } } |
In the noncompliant code example, p1
and p2
compare equal and p2
and p3
compare equal but p1
and p3
compare unequal; this violates the transitivity requirement. The problem is that the Card
class has no knowledge of the XCard
class and consequently cannot determine that p2
and p3
have different values for the field type
.
Compliant Solution
Wiki Markup |
---|
Unfortunately, it is impossible to extend an instantiable class (as opposed to an {{abstract}} class) by adding a value or field in the subclass while preserving the {{equals()}} contract. Use composition rather than inheritance to achieve the desired effect \[[Bloch 2008|AA. Bibliography#Bloch 08]\]. This compliant solution adopts this approach by adding a private {{card}} field to the {{XCard}} class and providing a {{public}} {{viewCard()}} method. |
Code Block | ||
---|---|---|
| ||
class XCard { private String type; private Card card; // Composition public XCard(int number, String type) { card = new Card(number); this.type = type; } public Card viewCard() { return card; } public boolean equals(Object o) { if (!(o instanceof XCard)) { return false; } XCard cp = (XCard)o; return cp.card.equals(card) && cp.type.equals(type); } public static void main(String[] args) { XCard p1 = new XCard(1, "type1"); Card p2 = new Card(1); XCard p3 = new XCard(1, "type2"); XCard p4 = new XCard(1, "type1"); System.out.println(p1.equals(p2)); // Prints false System.out.println(p2.equals(p3)); // Prints false System.out.println(p1.equals(p3)); // Prints false System.out.println(p1.equals(p4)); // Prints true } } |
Exceptions
Wiki Markup |
---|
*MET12-EX0:* This guideline may be violated provided that the incompatible types are never compared. There are classes in the Java platform libraries (and elsewhere) that extend an instantiable class by adding a value component. For example, {{java.sql.Timestamp}} extends {{java.util.Date}} and adds a nanoseconds field. The {{equals}} implementation for {{Timestamp}} violates symmetry and can cause erratic behavior if {{Timestamp}} and {{Date}} objects are used in the same collection or are otherwise intermixed. \[[Bloch 2008|AA. Bibliography#Bloch 08]\] |
Risk Assessment
Violating the general contract when overriding the equals()
method can lead to unexpected results.
Guideline | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
MET12-J | low | unlikely | medium | P2 | L3 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Bibliography
Wiki Markup |
---|
\[[API 2006|AA. Bibliography#API 06]\] [method equals()|http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#equals(java.lang.Object)] \[[Bloch 2008|AA. Bibliography#Bloch 08]\] Item 8: Obey the general contract when overriding equals \[[Darwin 2004|AA. Bibliography#Darwin 04]\] 9.2 Overriding the equals method |
MET11-J. Never declare a class method that hides a method declared in a superclass or superinterface 05. Methods (MET) MET13-J. Classes that define an equals() method must also define a hashCode() method