Why does the behavior of the Integer constant pool change at 127?

Question

I am not able to understand how the Java Constant Pool for Integer works.

I understand the behavior of Strings, and hence able to justify myself that it is the same case with Integer Constants also.

So, for Integers

Integer i1 = 127;
Integer i2 = 127;
System.out.println(i1==i2); // True

&

Integer i1 = new Integer(127);
Integer i2 = new Integer(127);
System.out.println(i1==i2); // False

Till here everything goes in my head.

What I am not able to digest is, it behaves differently when I increase the integer from 127. This behavior changes after 127, below is the code snippet

Integer i1 = 128;
Integer i2 = 128;
System.out.println(i1==i2); // False. WHY?????

Can somebody help me understand this?

Deplane

#1700581 – Scraggy

Answer 1

No, the constant pool for numbers doesn't work the same way as for strings. For strings, only compile-time constants are interned - whereas for the wrapper types for integer types, any boxing operation will always use the pool if it's applicable for that value. So for example:

int x = 10;
int y = x + 1;
Integer z = y; // Not a compile-time constant!
Integer constant = 11;
System.out.println(z == constant); // true; reference comparison

The JLS guarantees a small range of pooled values, but implementations can use a wider range if they wish.

Note that although it's not guaranteed, every implementation I've looked at uses Integer.valueOf to perform boxing operations - so you can get the same effect without the language's help:

Integer x = Integer.valueOf(100);
Integer y = Integer.valueOf(100);
System.out.println(x == y); // true

From section 5.1.7 of the JLS:

If the value p being boxed is true, false, a byte, or a char in the range \u0000 to \u007f, or an int or short number between -128 and 127 (inclusive), then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.

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. For other values, this formulation disallows any assumptions about the identity of the boxed values on the programmer's part. This would allow (but not require) sharing of some or all of these references.

This ensures that in most common cases, the behavior will be the desired one, without imposing an undue performance penalty, especially on small devices. Less memory-limited implementations might, for example, cache all char and short values, as well as int and long values in the range of -32K to +32K.

Fled

@user16320675: The latter, I think. I'm happy sticking to just the numeric behavior. – Fled

Answer 2

Java maintains Integer pool from -128 to 127

Declaring Integer like below

Integer i1 = 127;

Results in to

Integer i1 = Integer.valueOf(127);

So what actually happening for first case is

Integer i1 = 127;<---Integer.valueOf(127);
Integer i2 = 127;<---Integer.valueOf(127);<---Same reference as first

From source code of Integer for class valueOf method

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

So you get same reference if value is between -128 to 127 and you call valueOf else it just returns new Integer(i)

And because reference is same your == operator works for integers returned by valueOf between this range.

Archie

+1 for mentioning Integer.valueOf(). Other answers seem to think it's just magic. – Crow

Best explanation, This should be accepted answer – Staple

Answer 3

Java caches the integer objects in the range -128 to 127. So, when you try to assign a value in this range to a wrapper object, the boxing operation will invoke Integer.valueOf method and in turn it will assign a reference to the object already in the pool.

On the other hand, if you assign a value outside this range to a wrapper reference type, Integer.valueOf will create a new Integer object for that value. And hence, comparing the reference for Integer objects having value outside this range will give you false

So,

Integer i = 127;  --> // Equivalent to `Integer.valueOf(127)`
Integer i2 = 127;

// Equivalent to `Integer.valueOf(128)`
// returns `new Integer(128)` for value outside the `Range - [-128, 127]`
Integer i3 = 128; 
Integer i4 = 128;

System.out.println(i == i2); // true, reference pointing to same literal
System.out.println(i3 == i4); // false, reference pointing to different objects

But , when you create your integer instances using new operator, a new object will be created on Heap. So,

Integer i = new Integer(127);
Integer i2 = new Integer(127);

System.out.println(i == i2); // false

Mewl

Your i3 to i4 comparison is incorrect, as you're using int rather than Integer. – Fled

@JonSkeet. Oh! sorry. I should have had Integer at all the four places. Will Edit it. Thanks for pointing :) – Mewl

Answer is basically incorrect. Java does not 'cache integer literals'. Java caches the Integer objects from -128 to 127 if you call Integer.valueOf() to get them, which does happen in auto boxing, but not in OP's code, which is why it doesn't give the answer expected. – Crow

@EJP. Can you please remove your downvote now. Of course if you have downvoted. – Mewl

Certainly, when your answer is correct. Not before. I've provided quite enough information for you to correct it. You haven't assimilated it all yet. – Crow

@EJP. Ok, what's the problem now? – Mewl

You are now asking me to repeat what I've already written. I suggest you re-read it instead. Easier for me and more efficient for you. The parts in italics are there, and italicised, for a reason. – Crow

Answer 4

In short newer versions of Java cache Integer is in the -128 to 127 range (256 values). look here

What exactly does comparing Integers with == do?

Nickolai