Java defines the equality operators == and != for testing reference equality, but uses the Object.equals() method and its subclasses for testing abstract object equality. Naive programmers often confuse the intent of the == operation with that of the Object.equals() method. This confusion is frequently seen evident in the context of String processing.
As a general rule, use the Object.equals() method to check whether two objects are abstractly equal to each other. Reserve use of the equality operators == and != for testing whether two references specifically refer to the same object. (this This is reference equality.) . See also Also see guideline "MET13-J. Classes that define an equals() method must also define a hashCode() method."
This use of the equality operators also applies to numeric boxed types (for example,Byte, Character, Short, Integer, Long, Float, and Double), although the numeric relational operators (such as <, <=, >, and >=) produce results that match those provided for arguments of the equivalent primitive numeric types. See guideline "EXP03-J. Do not use the equality operators when comparing values of boxed primitives" for more information.
Noncompliant Code Example
The reference equality operator == evaluates to true only when the values it compares reference the same underlying object. This noncompliant example declares two distinct String objects that contain the same value to be true. The references, however, are unequal because they reference distinct objects.
...
Reference equality behaves like abstract object equality when comparing it is used to compare two strings that are each the result results of the String.intern() method. This solution can be used for fast string comparisons when only one copy of each string is required.
...
Use of String.intern() should be reserved for cases where the tokenization of strings either yields an important performance enhancement or dramatically simplifies code. The performance Performance and readability is are often improved by the use of code that applies the Object.equals() approach and lacks any dependence on reference equality.
The performance issue arises because:Performance issues arise because
- The cost of
String.intern()grows as the number of intern strings grows. Performance should be no worse than n log n, but the JLS Java Language Specification makes no guarantee. - Strings that have been interned become immortal; : they cannot be garbage collected. This can be problematic when large numbers of strings are interned.
Exceptions
EXP01-EX1: Use of Using reference equality in place of object equality is permitted only when the defining classes guarantee the existence of, at most, one object instance for each possible object value. This generally requires that instances of such classes are immutable. The use of static factory methods, rather than public constructors, facilitates instance control; this is a key enabling technique.
| Wiki Markup |
|---|
Objects that are instances of classes that provide this guarantee obey the invariant that, for any two references {{a}} and {{b}}, {{a.equals(b)}} is exactly equivalent to {{a == b}} \[[Bloch 2008|AA. Bibliography#Bloch 08]\]. The {{String}} class does not meet these requirements and, consequently, does not obey this invariant. |
...
Using reference equality to compare objects may can lead to unexpected results.
...
The Coverity Prevent Version 5.0 BAD_EQ checker can detect the instance instances where the "==" operator is being used for equality of objects when, ideally, the equal method should have been used. The "==" operator could consider the objects to be different when whereas the equals method considers would consider them to be the same.
Findbugs checks this guideline for type String.
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this guideline on the CERT website.
Related Guidelines
MITRE CWE: CWE-595 "Incorrect Syntactic Object Comparison"
...