Page History

The values of boxed primitives cannot be directly compared using the == and != operators , because these operators are reference comparison operatorscompare object references rather than object values. Programmers may can find this behavior surprising , however, because autoboxing memoizes, or caches, the values of some primitive valuesvariables. 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 Java Language SpecificationSection 5 (JLS), §5.1.7, "Boxing Conversion" [JLS 2015], explains which primitive values are memoized during autoboxing:

If the value p being boxed is true, false, a byte, a char in the range \u0000 to \u007f, or an int or short number between -128 and 127, then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.

Use of the == and != operators for comparing the values of fully memoized boxed primitive types is permitted.

Use of the == and != operators for comparing the values of boxed primitive types that are not fully memoized is permitted only when the range of values represented is guaranteed to be within the ranges specified by the JLS to be fully memoized.

Use of the == and != operators for comparing the values of boxed primitive types is not allowed in all other cases.

Note that Java Virtual Machine (JVM) implementations are allowed, but not required, to memoize additional values [JLS 2015]:

Less memory-limited implementations could, for example, cache all characters and shorts, as well as integers and longs in the range of −32K to +32K. (§5.1.7)

Code that depends on implementation-defined behavior is nonportable. It is permissible to depend on implementation-specific ranges of memoized values provided that all targeted implementations support these greater ranges.

Noncompliant Code Example

Wiki MarkupThis noncompliant code example (\[[Bloch 2009|AA. Bibliography#Bloch 09]\]), defines a {{Comparator}} with a {{compare()}} method. The {{ method [Bloch 2009]. The compare()}} method accepts two boxed primitives as arguments. The problem is the use of the {{==}} operator is used to compare the two boxed primitives; in this context it compares the _references_ to the wrapper objects rather than comparing the _values_ held in those objects. By comparison, the {{\<}} operator causes automatic unboxing of the primitive values and consequently operates as expected.primitives. In this context, however, it compares the references to the wrapper objects rather than comparing the values held in those objects.

import java.util.Comparator;
 
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 as because they are appropriately autoboxed at the call site.

Compliant Solution

To be compliant, use any of the four This compliant solution uses the comparison operators, <, >, <= and , or >= since , because these cause automatic unboxing of the primitive values. The == and != operators should not be used to compare boxed primitives.

import java.util.Comparator;
 
static Comparator<Integer> cmp = new Comparator<Integer>() { 
  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 in an attempt to compare two the values of pairs of Integer objects. According to guideline EXP01-J. Do not confuse abstract object equality with reference equality, for == to return true for two object references, they must point to the same underlying object. Results of using the == operator in this case will be misleadingHowever, the == operator compares object references rather than object values.

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);
 
 }
}

These comparisons generate the output sequence: true, false, false and true. The cache in the Integer class memoizes is guaranteed to cache only integer values from -128 to 127 to 128 only, which explains the output of the above code. Avoid this problem by using the equals() method instead of == to compare wrapper classes. See guideline EXP01-J for further details., which can result in equivalent values outside this range comparing as unequal when tested using the equality operators. 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 object1.the equals(object2) method instead of the == operator to compare the values of the objects. The results are program now prints true, false, true and , false on all platforms, 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, presumably, would presumably contains contain values of type int) fails at compile time because type int is not an object type. An important The appropriate declaration would be ArrayList<Integer>, which makes use of the wrapper classes and autoboxing is to store integer values in an ArrayList<Integer> instance.

This noncompliant code example attempts to count the number of integers indices in arrays list1 and list2 that have corresponding equivalent values. Recall that class Integer memoizes is required to memoize only those integer values in the range -−128 to 127 to 128; it returns non-unique objects for all values might return a nonunique object for any value outside that range. Consequently, when comparing autoboxed integer values outside that range, the == operator returns {{false}, might return false and the output of this example is example could deceptively output 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++;
      }
    }

    // printPrint the counter: 0 in this example
    System.out.println(counter);
  }

}

If the JLS specified the range of However, if the particular JVM running this code memoized integer values as -32768 to 32767, for examplefrom −32,768 to 32,767, all of the int values in the example would have been autoboxed to singleton the corresponding Integer objects, and the example code would have operated as intendedexpected. Because Using reference equality and value equality produce the same result only for values within the range of memoized values, and because that range is necessarily limited, successfully using reference equality in place of value equality instead of object equality requires that all values encountered fall within that range. A built-in dependence on "knowledge" of the specific value ranges that may be encountered is unreliable in the face of future changes to the codethe interval of values memoized by the JVM. The JLS lacks a specification of this interval; rather, it specifies a minimum range that must be memoized. 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++;
      }
    }
 
    // printPrint the counter: 10 in this example
    System.out.println(counter);
  }
}

Exceptions

Noncompliant Code Example (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 resultsEXP03-EX1: The values of autoboxed Boolean variables may be compared using the reference equality operators, because the Java language guarantees that the autoboxing yields either Boolean.True or Boolean.False (as appropriate); these objects are guaranteed to be singletons.

public void exampleEqualOperator(){
  
Boolean b1 = new Boolean("true"); //
 Or Boolean.True
Boolean b2 = new Boolean("true");

 // Orif Boolean.True
if(b1 == b2) {     // alwaysNever equal
   // System...out.println("Never printed");
  }
}

Compliant Solution (Boolean)

Boolean.TRUE, Boolean.FALSE, or the values of autoboxed true and false literals, 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 singletonsNote, however, that the constructors for class Boolean return distinct newly instantiated objects. Using the reference equality operators in place of value comparisons will yield unexpected results in this case.

public void exampleEqualOperator(){
  
Boolean b1 = new Boolean("true");
  Boolean b2 = new Boolean("true"); 
	
  if (b1 == b2) {   // neverAlways equal
  //  System...
}

...

out.println("Always printed");
  }
 
  b1 = Boolean.TRUE;
  if (b1 == b2) {   // Always equal
    System.out.println("Always printed");
  }
}

Risk Assessment

Using the equal and not equal equivalence operators to compare values of boxed primitives can lead to erroneous comparisons.

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.

...

Related Guidelines

Bibliography

[Bloch 2009]	Puzzle 4, "Searching for the One"
[JLS 2015]	§5.1.7, "Boxing Conversion"
[Pugh 2009]	Using == to Compare Objects Rather than .equals
[Seacord 2015]	Image Added EXP03-J. Do not use the equality operators when comparing values of boxed primitives LiveLesson

...

Image Added Image Added Image Added

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the CERT website.

Bibliography

\[[Bloch 2009|AA. Bibliography#Bloch 09]\] 4. "Searching for the One"
\[[JLS 2005|AA. Bibliography#JLS 05]\] [Section 5.1.7|http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.7], "Boxing Conversion"
\[[Pugh 2009|AA. Bibliography#Pugh 09]\] Using == to compare objects rather than .equals

EXP02-J. Use the two-argument Arrays.equals() method to compare the contents of arrays      04. Expressions (EXP)      EXP04-J. Beware of invisible implicit casts when using compound assignment operators