Integer class object

Question

I'd a code snippet:

public class Test{
    public static void main(String args[]){
        Integer a = 100;
        Integer b = 100;
        Integer c = 5000;
        Integer d = 5000;

        System.out.println(a);
        System.out.println(b);
        System.out.println(c);
        System.out.println(d);
        if(a == b)
            System.out.println("a & b Both are Equal");
        else
            System.out.println("a & b are Not Equal");
        if(c == d)
            System.out.println("c & d Both are Equal");
        else
            System.out.println("c & d are Not Equal");
    }
}

I'm not getting why the output is so? the Output is:
a & b Both are equal
c & d are not equal
I'm using jdk1.7

**Objects** are only `equal` when `equals()` is true. Using `==` means the **references** are the same. — Peter Lawrey, Nov 22 '11 at 09:31

score 7 · Accepted Answer · edited May 23 '17 at 11:55

7

This is due to an optimization in the virtual machine that maps small (frequently used) integers to a pool of objects that are reused. This answer explains some of the details.

edited May 23 '17 at 11:55

Community

1
1

answered Nov 22 '11 at 09:18

Björn Pollex

75,346
28
201
283

score 4 · Answer 2 · answered Nov 22 '11 at 09:20

4

It looks like that the java compiler is using cached values for the Integer objects. This cache is only populated for small inetger values. The value of 100 is in the cache so the object is re-used. The value of 5000 is not in the cahce and so new objects are created each time.

The == comparision test for object equality, not value equality hence why the cached objects are considered equal and the others are not.

answered Nov 22 '11 at 09:20

Brett Walker

3,566
1
18
36

can your statement be proved? – Mohammad Faisal Nov 22 '11 at 09:27
Please be more precise? Which statement needs to be proved? – Brett Walker Nov 22 '11 at 09:28
Its the JVM, not the compiler which caches Integer values. (In a class called IntegerCache ;) – Peter Lawrey Nov 22 '11 at 09:29
@Peter Yes the JVM caches the Integer, but the compiler asked the cache for the values. `new Integer(100) != new Integer(100)` but `Integer.valueOf("100") == Integer.valueOf("100")` – Brett Walker Nov 22 '11 at 09:33
@Brett Walker: `java compiler/jvm using cached values for Integer objects`. I want this statement to be proved. – Mohammad Faisal Nov 22 '11 at 09:34
They may or may not be cached depending on type. `Float.valueOf(float)` and `Double.valueOf(double)` are called but don't cache anything. Admittedly, the compiler allows the JVM to cache values. – Peter Lawrey Nov 22 '11 at 09:36
2

Prove is a bit strong. Demonstarte is perhaps whatyou mean. Look at this question: http://stackoverflow.com/questions/3934291/extending-java-integer-cahce – Brett Walker Nov 22 '11 at 09:37
2

@MohammadFaisal, If you want proof, I suggest you read the code, or read answers given before on this subject over the last 7 years, or read the JLS yourself. I am not sure what you are asking which has not been very well covered before. – Peter Lawrey Nov 22 '11 at 09:38

score 2 · Answer 3 · answered Nov 22 '11 at 09:24

You are comparing the address of the Integer objects using the == operator and the compiler must have simply re-used the a and b objects for the same variable but not the c and d objects. If you test equality using the equals method, then you get the desired results:

public class Test{
    public static void main(String args[]){
        Integer a = 100;
        Integer b = 100;
        Integer c = 5000;
        Integer d = 5000;

        System.out.println(a);
        System.out.println(b);
        System.out.println(c);
        System.out.println(d);
        if(a.equals(b))
            System.out.println("a & b Both are Equal");
        else
            System.out.println("a & b are Not Equal");
        if(c.equals(d))
            System.out.println("c & d Both are Equal");
        else
            System.out.println("c & d are Not Equal");
    }
}

100
100
5000
5000
a & b Both are Equal
c & d Both are Equal

score 0 · Answer 4 · answered Nov 22 '11 at 10:57

Boxing Conversion Boxing conversion converts values of primitive type to corresponding values of reference type. Specifically, the following 8 conversion are called the boxing conversions:

From type boolean to type Boolean From type byte to type Byte From type char to type Character From type short to type Short From type int to type Integer From type long to type Long From type float to type Float From type double to type Double At run time, boxing conversion proceeds as follows:

If p is a value of type boolean, then boxing conversion converts p into a reference r of class and type Boolean, such that r.booleanValue() == p If p is a value of type byte, then boxing conversion converts p into a reference r of class and type Byte, such that r.byteValue() == p If p is a value of type char, then boxing conversion converts p into a reference r of class and type Character, such that r.charValue() == p If p is a value of type short, then boxing conversion converts p into a reference r of class and type Short, such that r.shortValue() == p If p is a value of type int, then boxing conversion converts p into a reference r of class and type Integer, such that r.intValue() == p If p is a value of type long, then boxing conversion converts p into a reference r of class and type Long, such that r.longValue() == p If p is a value of type float then: If p is not NaN, then boxing conversion converts p into a reference r of class and type Float, such that r.floatValue() evaluates to p Otherwise, boxing conversion converts p into a reference r of class and type Float such that r.isNaN() evaluates to true. If p is a value of type double, then If p is not NaN, boxing conversion converts p into a reference r of class and type Double, such that r.doubleValue() evaluates to p Otherwise, boxing conversion converts p into a reference r of class and type Double such that r.isNaN() evaluates to true. If p is a value of any other type, boxing conversion is equivalent to an identity conversion (5.1.1). 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 Good read - http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.7

Integer class object

4 Answers4