Page History

"Ideally, boxing a given primitive value p, would always yield an identical reference. In practice, this may not be feasible using existing implementation techniques. The rules above are a pragmatic compromise. The final clause above requires that certain common values always be boxed into indistinguishable objects. The implementation may cache these, lazily or eagerly."(From section 5.1.7 of JLS 3rd Ed) 

Autoboxing can automatically wrap the primitive type to the corresponding wrapper object, which can be convenient in many cases and avoid clutters in your own code. But you should always be careful about this process, especially when comparison. Consider the following code:

...

true
false
false
true

...

Section 5.1.7 of JLS 3rd Ed can explain this problem clearly:

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

Here the cache in the Integer class can make the number from -127 to 128 reference to the same object, which clearly explains the result of above code.  In In case of that, when we need to do some comparison of these wrapper class, we should use equal instead "==" (see EXP03-J for details):

...

public class TestWrapper2 {
 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(i3.equals(i4));    
 }
} 

"Ideally, boxing a given primitive value p, would always yield an identical reference. In practice, this may not be feasible using existing implementation techniques. The rules above are a pragmatic compromise. The final clause above requires that certain common values always be boxed into indistinguishable objects. The implementation may cache these, lazily or eagerly."(From section 5.1.7 of JLS 3rd Ed)

To convince our idea, we can take an insight of the source code of Integer of JDK 1.6.0_10 J2SE:

 private static class IntegerCache {
 private IntegerCache(){}
 static final Integer cache[] = new Integer[-(-128) + 127 + 1];
 static {
     for(int i = 0; i < cache.length; i++)
        cache[i] = new Integer(i - 128);
 }
    }

Here there exists a cache in the Integer, which clearly explains the result of above code. It also means that if we have enough memory, we could caches all the integer value(-32K-32K), which means that all the int value could be autoboxing to the same Integer object. However, actually it is impractical, so we should be careful about using the following code.

Noncompliant Code Example

...

In JDK 1.6.0_10, the output of this code is 0. In this code, we want to count the same numbers of array list1 and array list2. Undoubtedly, the result is not the same as our expectation. But if we can set more caches inside Integer, then the (cach all the integer value(-32K-32K), which means that all the int value could be autoboxing to the same Integer object) then the result may be different!

Compliant solution

...