This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Integer problem Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Integer problem" Watch "Integer problem" New topic
Author

Integer problem

Gari Jain
Ranch Hand

Joined: Jun 29, 2009
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


OCPJP 6-100%; Preparing for GATE11
Ankit Garg
Sheriff

Joined: Aug 03, 2008
Posts: 9291
    
  17

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)...


SCJP 6 | SCWCD 5 | Javaranch SCJP FAQ | SCWCD Links
Gari Jain
Ranch Hand

Joined: Jun 29, 2009
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

Joined: Nov 04, 2009
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?


|BSc in Electronic Eng| |SCJP 6.0 91%| |SCWCD 5 92%|
Prasad Kharkar
Ranch Hand

Joined: Mar 07, 2010
Posts: 438

Wrapper classes are immutable classes

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

can you guess why?

SCJP 6 [86%] June 30th, 2010
OCPWCD [84%] March 26th, 2013
If you find any post useful, click the "plus one" sign on the right
Mark Kramer
Greenhorn

Joined: Sep 02, 2010
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.


OCPJP 6 | CompTIA A+, Security+, Network+, Project + | IBM AS/400 RPG Programmer, iSeries System Administration V5R2, Power Systems Technical Support for i | CIW Associate, Professional, Web Development Professional | MCTS
Mark Kramer
Greenhorn

Joined: Sep 02, 2010
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

Joined: Jun 29, 2009
Posts: 100
Thankyou, Mark Kramer, Prasad Kharkar, Abimaran Kugathasan, Ankit Garg
 
wood burning stoves
 
subject: Integer problem
 
Similar Threads
Wrapper Classes Autoboxing Concept
Doubt in K&B SCJP :Page 236
equals method .. comparing objects
boxing,==, and equals()
Integer unboxing and == operator question