• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Integer problem

 
Ranch Hand
Posts: 100
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
 
Sheriff
Posts: 9707
43
Android Google Web Toolkit Hibernate IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 2066
IntelliJ IDE Clojure Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Eclipse IDE MySQL Database Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Wrapper classes are immutable classes

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

can you guess why?
 
Greenhorn
Posts: 23
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thankyou, Mark Kramer, Prasad Kharkar, Abimaran Kugathasan, Ankit Garg
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic