The values of boxed primitives cannot be directly compared using the ==
and !=
operators because they compare object references, not object values. Programmers could find this behavior surprising because autoboxing memoizes, or caches, the values of some primitive variables. Consequently, reference comparisons and value comparisons produce identical results for the subset of values that are memoized.
Autoboxing automatically wraps a value of a primitive type with the corresponding wrapper object. The §5.1.7, "Boxing Conversion," of the Java Language Specification [[JLS 2005]] explains which primitive values are memoized during autoboxing:
If the value
p
being boxed istrue
,false
, abyte
, achar
in the range\u0000
to\u007f
, or anint
orshort
number between-128
and127
, then letr1
andr2
be the results of any two boxing conversions ofp
. It is always the case thatr1 == r2
.
Primitive Type |
Boxed Type |
Fully Memoized |
---|---|---|
|
|
yes |
|
|
no |
The ==
and !=
operators may be used to compare the values of fully memoized types.
The ==
and !=
operators may only be used for comparing the values of boxed primitives that are not fully memoized when the range of values represented is guaranteed to be within the ranges specified by the Java Language Specification to be fully memoized.
In general, avoid using these operators to compare the values of boxed primitives that are not fully memoized.
Implementations are allowed, but not required, to memoize additional values:
Less memory-limited implementations could, for example, cache all characters and shorts, as well as integers and longs in the range of -32K — +32K.
Code that depends on implementation-defined behavior is not portable.
Noncompliant Code Example
This noncompliant code example defines a Comparator
with a compare()
method [[Bloch 2009]]. The compare()
method accepts two boxed primitives as arguments. The ==
operator is used to compare the two boxed primitives. In this context, however, it compares the references to the wrapper objects rather than comparing the values held in those objects.
static Comparator<Integer> cmp = new Comparator<Integer>() { public int compare(Integer i, Integer j) { return i < j ? -1 : (i == j ? 0 : 1); } };
Note that primitive integers are also accepted by this declaration because they are autoboxed at the call site.
Compliant Solution
This compliant solution uses the comparison operators, <
, >
, <=
, or >=
, because these cause automatic unboxing of the primitive values. The ==
and !=
operators should not be used to compare boxed primitives.
public int compare(Integer i, Integer j) { return i < j ? -1 : (i > j ? 1 : 0) ; }
Noncompliant Code Example
This noncompliant code example uses the ==
operator to compare two Integer
objects. According to the guideline, "EXP01-J. Do not confuse abstract object equality with reference equality," for the ==
operator to return true
for two object references, they must point to the same underlying object.
public class Wrapper { public static void main(String[] args) { Integer i1 = 100; Integer i2 = 100; Integer i3 = 1000; Integer i4 = 1000; System.out.println(i1 == i2); System.out.println(i1 != i2); System.out.println(i3 == i4); System.out.println(i3 != i4); } }
The Integer
class only caches integer values from -127
to 128
, which can result in equivalent values outside this range not comparing equal. For example, a JVM that did not cache any other values when running this program would output
true false false true
Compliant Solution
This compliant solution uses the equals()
method instead of the ==
operator to compare the values of the objects. The program now prints true
, false
, true
, false
on any platform, as expected.
public class Wrapper { public static void main(String[] args) { Integer i1 = 100; Integer i2 = 100; Integer i3 = 1000; Integer i4 = 1000; System.out.println(i1.equals(i2)); System.out.println(!i1.equals(i2)); System.out.println(i3.equals(i4)); System.out.println(!i3.equals(i4)); } }
Noncompliant Code Example
Java Collections contain only objects; they cannot contain primitive types. Further, the type parameters of all Java generics must be object types rather than primitive types. That is, attempting to declare an ArrayList<int>
(which would, presumably, contain values of type int
) fails at compile time because type int
is not an object type. The appropriate declaration would be ArrayList<Integer>
, which makes use of the wrapper classes and autoboxing.
This noncompliant code example attempts to count the number of indices in arrays list1
and list2
that have equivalent values. Recall that class Integer
needs to memoize only those integer values in the range -127 to 128; it might return non-unique objects for all values outside that range. Consequently, when comparing autoboxed integer values outside that range, the ==
operator might return false
, and the output of this example might be 0.
public class Wrapper { public static void main(String[] args) { // Create an array list of integers, where each element // is greater than 127 ArrayList<Integer> list1 = new ArrayList<Integer>(); for (int i = 0; i < 10; i++) { list1.add(i + 1000); } // Create another array list of integers, where each element // has the same value as the first list ArrayList<Integer> list2 = new ArrayList<Integer>(); for (int i = 0; i < 10; i++) { list2.add(i + 1000); } // Count matching values. int counter = 0; for (int i = 0; i < 10; i++) { if (list1.get(i) == list2.get(i)) { // uses '==' counter++; } } // print the counter: 0 in this example System.out.println(counter); } }
If the particular JVM running this code memoized integer values from -32,768 to 32,767, all of the int
values in the example would have been autoboxed to singleton Integer
objects, and the example code would have operated as expected. Using reference equality instead of object equality requires that all values encountered fall within the interval of values memoized by the JVM. The Java Language Specification does not specify this interval; it only provides a minimum range. Consequently, successful prediction of this program's behavior would require implementation-specific details of the JVM.
Compliant Solution
This compliant solution uses the equals()
method to perform value comparisons of wrapped objects. It produces the correct output 10.
public class Wrapper { public static void main(String[] args) { // Create an array list of integers, where each element // is greater than 127 ArrayList<Integer> list1 = new ArrayList<Integer>(); for (int i = 0; i < 10; i++) { list1.add(i + 1000); } // Create another array list of integers, where each element // has the same value as the first one ArrayList<Integer> list2 = new ArrayList<Integer>(); for (int i = 0; i < 10; i++) { list2.add(i + 1000); } // Count matching values int counter = 0; for(int i = 0; i < 10; i++) { if (list1.get(i).equals(list2.get(i))) { // uses 'equals()' counter++; } } // print the counter: 10 in this example System.out.println(counter); } }
Noncompliant Code Example (new Boolean
)
In this noncompliant code example, constructors for class Boolean
return distinct newly-instantiated objects. Using the reference equality operators in place of value comparisons will yield unexpected results.
public void exampleEqualOperator(){ Boolean b1 = new Boolean("true"); Boolean b2 = new Boolean("true"); if( b1 == b2 ) // never equal System.out.println("Never printed"); }
Compliant Solution (new Boolean
)
In this compliant solution, the values of autoboxed Boolean
variables may be compared using the reference equality operators because the Java language guarantees that the Boolean
type is fully memoized. Consequently, these objects are guaranteed to be singletons.
public void exampleEqualOperator(){ Boolean b1 = true; // Or Boolean.True Boolean b2 = true; // Or Boolean.True if(b1 == b2) // always equal System.out.println("Will always be printed"); }
Exceptions
EXP03-EX1 In the unusual case where a program is guaranteed to execute only on a single implementation, it is permissible to depend upon implementation-specific ranges of memoized vulnerabilities.
Risk Assessment
Using the equivalence operators to compare values of boxed primitives can lead to erroneous comparisons.
Guideline |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
EXP03-J |
low |
likely |
medium |
P6 |
L2 |
Automated Detection
Detection of all uses of the reference equality operators on boxed primitive objects is straightforward. Determining the correctness of such uses is infeasible in the general case.
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="ccd95d76-c5f9-4dac-9f7a-96cf4875e845"><ac:plain-text-body><![CDATA[ |
[[Bloch 2009 |
AA. Bibliography#Bloch 09]] |
4. "Searching for the One" |
]]></ac:plain-text-body></ac:structured-macro> |
|
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="41aa36a8-af33-42dd-b215-e017e3c14341"><ac:plain-text-body><![CDATA[ |
[[JLS 2005 |
AA. Bibliography#JLS 05]] |
[§5.1.7, "Boxing Conversion" |
http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.7] |
]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="48c6e492-7b83-47a4-8000-72c57f7e9f26"><ac:plain-text-body><![CDATA[ |
[[Pugh 2009 |
AA. Bibliography#Pugh 09]] |
Using == to compare objects rather than .equals |
]]></ac:plain-text-body></ac:structured-macro> |
EXP02-J. Use the two-argument Arrays.equals() method to compare the contents of arrays 02. Expressions (EXP) EXP04-J. Do not perform assignments in conditional statements