Integer problem

Gari Jain
Ranch Hand
Posts: 100

K&B: Page-246

In order to save memory, two instances of the
following wrapper objects (created through boxing), will always be == when their
primitive values are the same:
■ Boolean
■ Byte
■ Character from \u0000 to \u007f (7f is 127 in decimal)
■ Short and Integer from -128 to 127

When I try the code below:

Output is:
x is 401y is 400
false

The above two concepts(one is the quote and the other one is the concept in the program) are getting all mixed up in my mind. And also I am trying to relate it with Strings and String Builders.(Are Strings and Wrappers somewhat similar in this concept?)

As written in Quote- In order to save memory Integers from -127 to 128 are always equal. Similar is the case with String Pool.Is there any such thing as.."Integer Pool"?

Please point out the similarities and differences.

Thankyou

Ankit Garg
Sheriff
Posts: 9529
33
1. In your program the value of x and y are different. So there is no way the == comparison would come as true. You can say that the values between -128 to 127 is stored in an integer pool. So if I write this
In this case both x and y point to the same Integer object (the integer pool)...

Gari Jain
Ranch Hand
Posts: 100
Yes, thats OK. But what about the values above 128? If those values don't get stored in the integer pool, then why in the example below:

why 'x' starts pointing to a new object when it's value is changed while 'y' still points to the previous object(this behaviour is shown by the objects in Integer Pool).
If values above 128 aren't stored in an integer pool then 'x' should keep pointing to the old object, and this x==y should return true??

Integer is implementing some partial integer pool here??? This is confusing me!
What exactly is going on here?

Abimaran Kugathasan
Ranch Hand
Posts: 2066
Gari Jain wrote:why 'x' starts pointing to a new object when it's value is changed while 'y' still points to the previous object(this behaviour is shown by the objects in Integer Pool).

First of all, Wrapper objetc are immutable, so, if you've changed the value of x, then it'll point to another new object!
try this,

It'll give you a compilation error! Could you spot it, why?

Ranch Hand
Posts: 446
1
Wrapper classes are immutable classes

here
Integer y = x
and
x++
these are different things

can you guess why?

Mark Kramer
Greenhorn
Posts: 23
Gari Jain wrote:
Integer is implementing some partial integer pool here??? This is confusing me!
What exactly is going on here?

I think the point here is that whether Integers are stored in a pool or not, they are still immutable. When you increment x, it will never affect the value of other Integers. Someone correct me if I'm wrong but I believe the authors are saying 1) Integers in the range of -128 to 127 are stored in a pool and equal values will always reference the same object 2) Integers outside of this range are not guaranteed to reference the same object even if they have the same value, and 3) Integers are immutable. i.e. changing a value will always result in a different object reference.

The bottom line is that you should use the equals() method when comparing Integers because == is only reliable in a narrow range of values.

Mark Kramer
Greenhorn
Posts: 23
I ran the program below to test the concept and it does appear that Integers outside of the range -128 to 127 are never == with equal values, and within the range they are always == with equal values. Perhaps there is no such thing as an Integer pool outside of this range? Nonetheless, Integers are always immutable -- immutability and pools are two different concepts.

Gari Jain
Ranch Hand
Posts: 100
Thankyou, Mark Kramer, Prasad Kharkar, Abimaran Kugathasan, Ankit Garg