Integer wrapper class and == operator - where is behavior specified? [duplicate]

Question

Integer integer1 = 127;
Integer integer2 = 127;
System.out.println(integer1 == integer2);//true

integer1 = 128;
integer2 = 128;
System.out.println(integer1 == integer2);//false

I found it returns == (if it is) under the range of -128 - 127 , why is there such specification ?

Tantalate

Answer 1

Because of this code in Integer.valueOf(int):

public static Integer valueOf(int i) {
    if(i >= -128 && i <= IntegerCache.high)
        return IntegerCache.cache[i + 128];
    else
        return new Integer(i);
}

Explanation:

Integer integer1 = 127 is a shortcut for Integer integer1 = Integer.valueOf(127), and for values between -128 and 127 (inclusive), the Integers are put in a cache and returned multiple times, while higher and lower numbers generate new Integers each time.

Triumph

Add to that, JDK specs say Integers between -128 and 128 are cached. Depending on your JDK, additional values may also be cached. – Baseler

Ok. what is the significance of this, isn't it a easter egg, won't it lead to some bad thing>? – Tantalate

@Jigar No, it's documented behavior. Problems only result if you compare objects with ==. Use == for primitives and equals() for Objects. Integer is an Object, not a primitive. – Triumph

Answer 2

== will return true if it's the exact same object. Boxing integers in Java 'intern' numbers within that that range, so any boxed version of such a number will result in the exact same object.

To get avoid this effect in comparisons, use .equals()

System.out.println(integer1.equals(integer2));

Andantino

Ok. what is the significance of this, isn't it a easter egg, won't it lead to some bad thing>? – Tantalate

If you use .equals() to compare the content of a variable and == to compare the actual object references no bad things will happen, trust me. – Andantino