Why is == true for some Integer objects?

Question

Possible Duplicate:
Integer wrapper objects share the same instances only within the value 127?

I have copied the following program snippet from the Khalid Mughal SCJP, but I am unable to
understand the output.

 public class RQ200_60 {
    public static void main(String[] args) {
        Integer i = -10;
        Integer j = -10;
        System.out.print(i==j);         // output: true -- why true?
        System.out.print(i.equals(j));  // output: true
        Integer n = 128;
        Integer m = 128;
        System.out.print(n==m);         // output: false
        System.out.print(n.equals(m));  // output: true
    }
}

The above program giving output true for the first print statement but it supposed to give false because it is reference comparison with == relational operator. But third print gives false and I don't understand this inconsistency.

Explanations are greatly appreciated!

http://stackoverflow.com/questions/7309640/compare-two-integer , http://stackoverflow.com/questions/5581913/wrapper-class-and-operator , http://stackoverflow.com/questions/5117132/wrapper-objects-share-the-same-address-space-only-within-the-value-127 , http://stackoverflow.com/questions/5865056/integer-construction-variations — , Dec 08 '11 at 07:25

score 36 · Accepted Answer · edited May 23 '17 at 12:14

36

In the first case, both the objects i and j are pointing to the same cached object. By default, the range between -128 and 127 are cached as Integer Object. We can increase the range using JVM arguments

edited May 23 '17 at 12:14

Community

1
1

answered Dec 08 '11 at 07:10

Prince John Wesley

62,492
12
87
94

5

+1 Interesting, didn't know that was configurable. – Paul Bellora Dec 08 '11 at 07:16
3

I also didn't know it's configurable. Autoboxed values from -128 to 127 *must* be identity-equal according to [JLS 5.1.7](http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.1.7) – yshavit Dec 08 '11 at 07:27

score 13 · Answer 2 · edited Dec 08 '11 at 07:19

13

The answers about caching are correct. However, if you go...

Integer i = new Integer(10);
Integer j = new Integer(10);

...then you avoid the caching and the results will be what you expected.

edited Dec 08 '11 at 07:19

answered Dec 08 '11 at 07:17

user949300

15,364
7
35
66

@pst thanks for the edit. Typing on my Nook is a bit awkward. – user949300 Dec 08 '11 at 07:32

score 8 · Answer 3 · answered Dec 08 '11 at 07:10

Integer objects may be cached for the ones that represent a value close to 0. (The specification for the implementation may tell you some details). This is presumably to save memory (values close to 0 are common, and it would waste a lot of memory to make a new object for every variable with the same value).

== checks whether two things are the same object; you may or may not have the same Integer object for any two given variables with the same value. You are not supposed to check with == because you are not supposed to care whether it is the same object; it is the value of an Integer that matters, not its identity.

score 1 · Answer 4 · answered Dec 08 '11 at 08:04

1

Here in this case the Integer i and Integer j holding the integer values which are in range of integer, range of an Integer is -128 to 128, and Integer n and Integer m exceeds the range of Integer

answered Dec 08 '11 at 08:04

Jimshad Abdulla

167
2
8

Why is == true for some Integer objects?

4 Answers4

Linked

Related