Java defines the equality operators ==
and !=
for testing reference equality but uses the Object.equals()
method defined in Object
and its subclasses for testing abstract object equality. Naive Naïve programmers often confuse the intent of the ==
operation with that of the Object.equals()
method. This confusion is frequently evident in the context of processing String
objects.
...
Numeric boxed types (for example, Byte
, Character
, Short
, Integer
, Long
, Float
, and Double
) should also be compared using Object.equals()
and not rather than the ==
operator. While reference equality may appear to work for Integer
values between the range -128 −128 and 127, it may fail if either of the operands in the comparison are outside that range. Numeric relational operators other than equality (such as <
, <=
, >
, and >=
) can be safely used to compare boxed primitive types (see EXP03-J. Do not use the equality operators when comparing values of boxed primitives for more information).
Noncompliant Code Example
This noncompliant code example declares two distinct String
objects that contain the same value.:
Code Block | ||
---|---|---|
| ||
public class StringComparison { public static void main(String[] args) { String str1 = new String("one"); String str2 = new String("one"); System.out.println(str1 == str2); // Prints "false" } } |
The reference equality operator ==
evaluates to true
only when the values it compares refer to the same underlying object. The references in this example are unequal because they refer to distinct objects.
Compliant Solution (Object.equals()
)
This compliant solution uses the Object.equals()
method when comparing string values:
Code Block | ||
---|---|---|
| ||
public class StringComparison { public static void main(String[] args) { String str1 = new String("one"); String str2 = new String("one"); System.out.println(str1.equals( str2)); // Prints "true" } } |
Compliant Solution (String.intern()
)
Reference equality behaves like abstract object equality when it is used to compare two strings that are results of the String.intern()
method. This compliant solution uses String.intern()
and can perform fast string comparisons when only one copy of the string one
is required in memory.
...
The Java Language Specification (JLS) [JLS 2013] provides very limited guarantees about the implementation of String.intern()
. For example,
- The cost of
String.intern()
grows as the number of intern strings grows. Performance should be no worse than O(n log n), but the Java Language Specification JLS lacks a specific performance guarantee. - In early Java Virtual Machine (JVM) implementations, interned strings became immortal: they were exempt from garbage collection. This can be problematic when large numbers of strings are interned. More recent implementations can garbage-collect the storage occupied by interned strings that are no longer referenced. However, the Java Language Specification lacks the JLS lacks any specification of this behavior.
- In JVM implementations prior to Java 1.7, interned strings are allocated in the
permgen
storage region, which is typically much smaller than the remainder rest of the heap. Consequently, interning large numbers of strings can lead to an out-of-memory condition. In many Java 1.7 implementations, interned strings are allocated on the heap, relieving this restriction. Once again, the details of allocation are unspecified by the Java Language SpecificationJLS; consequently, implementations may vary.
String interning is also a favorable technique for may also be used in programs that accept repetitively occurring strings. Its use boosts the performance of comparisons and minimizes memory consumption.
When canonicalization of objects is required, it may be wiser to use a custom canonicalizer built on top of ConcurrentHashMap
; see Joshua Bloch's Effective Java, second edition, Item 69 [Bloch 2008], for details.
Applicability
Using Confusing reference equality to compare objects and object equality can lead to unexpected results.
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 the class to be a singleton. The use of static factory methods, rather than public constructors, facilitates instance control; this is a key enabling technique. Another technique is to use an enum
type.
Use reference equality to determine whether two references point to the same object.
Related Guidelines
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
The Checker Framework |
| Interning Checker | Check for errors in equality testing and interning (see Chapter 5) | ||||||
Parasoft Jtest |
| CERT.EXP50.UEIC | Do not use '==' or '!=' to compare objects | ||||||
SonarQube |
| S1698 |
CWE-595, Comparison of object references instead of object contents
CWE-597, Use of wrong operator in string comparison
equals()
, not ==
, to test for equality of objectsBibliography
[Bloch 2008] | Item 69, "Prefer Concurrency Utilities to wait and notify " |
ES, "Comparison of String Objects Using | |
[JLS |
2013] | §3.10.5, "String Literals" |
...
...