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 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. Programs must reserve use of the equality operators ==
and !=
for testing whether two references specifically refer to the same object; this is reference equality. Also see rule " MET09-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 rule "EXP03-J. Do not use the equality operators when comparing values of boxed primitives" for more information.
Noncompliant Code Example
...
Use of String.intern()
should be reserved for cases where in which the tokenization of strings either yields an important performance enhancement or dramatically simplifies code. Performance and readability are often improved by the use of code that applies the Object.equals()
approach and lacks any dependence on reference equality.
...
- The cost of
String.intern()
grows as the number of intern strings grows. Performance should be no worse than n log n, but the Java Language Specification lacks a specific performance guarantee. - Strings that have been interned Interned strings become immortal: they cannot be garbage-collected. This can be problematic when large numbers of strings are interned.
...
EXP01-EX0: 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 , which 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}} \[java:[Bloch 2008|AA. References#Bloch 08]\]. The {{String}} class fails to meet these requirements and, consequently, fails to preserve this invariant. |
...
The Coverity Prevent Version 5.0 BAD_EQ checker can detect instances where the ==
operator is being used for equality of objects when, ideally, the equal equals()
method should have been used. The ==
operator could consider the objects to be different, whereas the equals()
method would consider them to be the same.
...
CWE ID 595, "Comparison of Object References Instead of Object Contents" | |
| CWE ID 597, "Use of Wrong Operator in String Comparison" |
The Elements of Java Style | Rule 79: Use |
...
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="65c4da407513cfb1-84daccfb-479b4dc2-a7c88e45-4bed47c1acac0c48a1b0718b"><ac:plain-text-body><![CDATA[ | [java:[FindBugs 2008 | AA. References#FindBugs 08]] | ES: Comparison of String objects using == or != | ]]></ac:plain-text-body></ac:structured-macro> | |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="4d0168537cc9cf83-86a36e5f-45e147cd-ab3bbaff-d9107859c2d34a15770d9f6c"><ac:plain-text-body><![CDATA[ | [java:[JLS 2005 | AA. References#JLS 05]] | [§3.10.5, "String Literals" | http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.5] | ]]></ac:plain-text-body></ac:structured-macro> |
|
...