Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The values of boxed primitives cannot be directly compared using the == and != operators because these operators compare object references , rather than object values. Programmers could can 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.

Wiki MarkupAutoboxing automatically wraps a value of a primitive type with the corresponding wrapper object. The [§5 The Java Language Specification (JLS), §5.1.7, "Boxing Conversion,"|http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.7] of the _Java Language Specification_ \[[JLS 2005|AA. Bibliography#JLS 05]\] explains which primitive values are memoized during autoboxing: " [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 \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.

Primitive Type

Boxed Type

Fully Memoized

boolean, byte

Boolean, Byte

yes

Yes

char, short, int

Char, Short, Int

no

No

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 Java Language Specification 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 — −32K to +32K. (§5.1.7)

Code that depends on implementation-defined behavior is non-portablenonportable. 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 defines a {{Comparator}} with a {{compare()}} method \ [[Bloch 2009|AA. Bibliography#Bloch 09]\]. 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.

Code Block
bgColor#FFCCCC
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);
  } 
};

...

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.

Code Block
bgColor#ccccff

public int compare(Integer 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 the values of pairs of Integer objects. However, the == operator compares object references rather than object values.

Code Block
bgColor#FFCCCC

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 is only guaranteed to cache only integer values from -128 to 127 to 128, 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

Code Block

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 all platforms, as expected.

Code Block
bgColor#CCCCFF

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

...

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, would 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 is required to to memoize only those integer values in the range -−128 to 127 to 128; it might return a non-unique nonunique object for any value 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 0example could deceptively output 0.

Code Block
bgColor#FFCCCC

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)) {  // usesUses '=='
        counter++;
      }
    }

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

}

If However, if the particular JVM running this code memoized integer values from -32−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 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 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.

...

This compliant solution uses the equals() method to perform value comparisons of wrapped objects. It produces the correct output, 10.

Code Block
bgColor#CCCCFF

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))) {  // usesUses 'equals()'
        counter++;
      }
    }
 
    // printPrint the counter: 10 in this example
    System.out.println(counter);
  }
}

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 results.

Code Block
bgColor#FFCCCC

public void exampleEqualOperator(){

  Boolean b1 = new Boolean("true");
  Boolean b2 = new Boolean("true");

  if ( b1 == b2 )    {       // neverNever equal
    System.out.println("Never printed");
  }
}

Compliant Solution (

...

Boolean)

In this compliant solution, the values of autoboxed Boolean variables may be compared Boolean.TRUEBoolean.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 singletons.

Code Block
bgColor#CCCCFF

public void exampleEqualOperator(){

  Boolean b1 = true; // Or Boolean.True
  Boolean b2 = true; // Or Boolean.True
	
  if (b1 == b2) {         // alwaysAlways equal
    System.out.println("Will always beAlways printed");
  }
}

Exceptions

EXP03-EX0 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

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

Risk Assessment

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

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

EXP03-J

low

Low

likely

Likely

medium

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.

Related Guidelines

MITRE CWE

CWE-595, "Comparison of Object References Instead of Object Contents"

 

CWE-597, "Use of Wrong Operator in String Comparison"

Bibliography

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="09c04181-2cbe-4352-abda-57fff479d1ff"><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="775feb9e-dfda-4761-bc9b-f7d0969a69ab"><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="109f9dc2-71fa-4938-9b06-a23ab6690b12"><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>

Tool
Version
Checker
Description
CodeSonar
Include Page
CodeSonar_V
CodeSonar_V

JAVA.COMPARE.EMPTYSTR
JAVA.COMPARE.EQ
JAVA.COMPARE.EQARRAY

Comparison to Empty String (Java)
Should Use equals() Instead of == (Java)
equals on Array (Java)

Coverity7.5

BAD_EQ
FB.EQ_ABSTRACT_SELF
FB.EQ_ALWAYS_FALSE
FB.EQ_ALWAYS_TRUE
FB.EQ_CHECK_FOR_OPERAND_NOT_ COMPATIBLE_WITH_THIS
FB.EQ_COMPARETO_USE_OBJECT_ EQUALS
FB.EQ_COMPARING_CLASS_NAMES
FB.EQ_DOESNT_OVERRIDE_EQUALS
FB.EQ_DONT_DEFINE_EQUALS_ FOR_ENUM
FB.EQ_GETCLASS_AND_CLASS_ CONSTANT
FB.EQ_OTHER_NO_OBJECT
FB.EQ_OTHER_USE_OBJECT
FB.EQ_OVERRIDING_EQUALS_ NOT_SYMMETRIC
FB.EQ_SELF_NO_OBJECT
FB.EQ_SELF_USE_OBJECT
FB.EQ_UNUSUAL
FB.ES_COMPARING_PARAMETER_ STRING_WITH_EQ
FB.ES_COMPARING_STRINGS_ WITH_EQ
FB.ES_COMPARING_PARAMETER_ STRING_WITH_EQ

Implemented
Parasoft Jtest
Include Page
Parasoft_V
Parasoft_V
CERT.EXP03.UEICDo not use '==' or '!=' to compare objects
PVS-Studio

Include Page
PVS-Studio_V
PVS-Studio_V

V6013
SonarQube
Include Page
SonarQube_V
SonarQube_V
S1698"==" and "!=" should not be used when "equals" is overridden

Related Guidelines

MITRE CWE

CWE-595, Comparison of Object References Instead of Object Contents
CWE-597, Use of Wrong Operator in String Comparison

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 Image Added Image AddedEXP02-J. Use the two-argument Arrays.equals() method to compare the contents of arrays      02. Expressions (EXP)      EXP04-J. Ensure that autoboxed values have the intended type