Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

classes Wrapper

 
Bruno Sant Ana
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys,

I'm studying to get a Java certificate, therefore I'm reading Kathy Sierra's book. On page 135 I found something that appears very strange to me. First I declare two Integer objects(i1 and i2) and compare both of them using != and after that using equals. The output says that they are different objects but meaningfully equal. In the second part of the code I create two Integer objects(i3 and i4) and compare them using == and equal. It seems that i3 and i4 are the same object(at least the output says that), but it isn't true in my point of view, and I don't understand why i1 and i2 are different and i3 and i4 are the same. What mess in my head. Does anybody help me to understand this code bellow? Thanks and sorry my bad english.

 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When you assign a primitive to an wrapper class, such as Integer i = 123, that's autoboxing. The compiler inserts a call to Integer.valueOf(123), this, in turn, may create a new Object, or may simply return a reference to an object in the constant pool. The default for the constant pool is integers in the range -128..127, however, it can be configured at JVM startup with a command line parameter.

So, when you autobox an int in the range -128..127, you get an object from the pool, so the same int value there gets mapped to the same single Integer object. And when you autobox an int outside that range, a new Integer object is created each time.

HOWEVER, if you write your Java code correctly, you'll never need to know this. That is, if you want to see if two objects hold the same "contents" or "value", you must always use equals(). When you do that correctly, it won't ever matter whether the objects were cached or not.

The only time to use == is when you want to see if two references point to the same object, and there are not many use cases where that arises. The main one is as a shortcut in implementing equals()--the first step is often if (that == this) reutrn true; Other than that, there are precious few occasions when it is correct to use == for reference types.
 
dennis deems
Ranch Hand
Posts: 808
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Integer objects whose values are between -128 and 127 are cached. When a value is assigned to an Integer reference, if the value is cached then that will be used instead of creating a redundant object. You can defeat this by using the "new" keyword: Integer i5 = new Integer( 10 ) always creates a new object even if an Integer with value 10 already exists.

Edit: too slow.
 
Rob Spoor
Sheriff
Pie
Posts: 20531
54
Chrome Eclipse IDE Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to the Ranch, Bruno!

Could you please SearchFirst next time? This exact same question has been asked several times before.
 
Bruno Sant Ana
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey,

Thanks Jeff and Dennis, I think I understood this matter.

Rob, I should have searched before posting, I'm sorry. Here is the code that I used to test and I think it can help others. Guys, please just review my code and the comments that I added to it and if it's correct I'll be happy in closing this post:



The output is like that:


different objects
different objects
different objects
different objects
same object
same object
same object
 
Campbell Ritchie
Sheriff
Pie
Posts: 48968
60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you look in the Java Language specification (JLS) and the Integer class, you will find about wrapper class caching. Note that it does not say that values between -128 and +127 are cached, if you read the small print in the JLS.
 
Rob Spoor
Sheriff
Pie
Posts: 20531
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But the Javadoc of Integer.valueOf(int) does:
This method will always cache values in the range -128 to 127, inclusive, and may cache other values outside of this range.


[fixed typo]
 
Campbell Ritchie
Sheriff
Pie
Posts: 48968
60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, it doesn’t say “-128 to 127”. It says “-128 to 127 and maybe more”.
I was a bit imprecise in what I said yesterday.
 
Rob Spoor
Sheriff
Pie
Posts: 20531
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let's just agree that I've misinterpreted what you were trying to say.
 
Campbell Ritchie
Sheriff
Pie
Posts: 48968
60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And let’s agree that I didn’t say it at all clearly. Sorry.
 
Rob Spoor
Sheriff
Pie
Posts: 20531
54
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're forgiven
 
Campbell Ritchie
Sheriff
Pie
Posts: 48968
60
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic