• Post Reply Bookmark Topic Watch Topic
  • New Topic

discrepancy in comparison (==)  RSS feed

 
Manoj Kumar Jain
Ranch Hand
Posts: 198
Java Linux Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I have one query when I ran below code.


I got the output as below:
i1 and i2 are equal


While as you can see i3 and i4 are also equal. I know that comparing objects with == operator is actully comparing their refrences, not the value of object.
My question is that why i3 and i4's refrence are not equal and why i1==i2.(I can see upto value of 127 i1 will be == to i2)

Is this something related to compiler to save the memory space by allocating the same memory address to equal value objects. ??

Thanks is advance
 
Matthew Brown
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Manoj Kumar Jain wrote:My question is that why i3 and i4's refrence are not equal and why i1==i2.(I can see upto value of 127 i1 will be == to i2)

I'm a little confused here, because by saying "I can see up to value of 127 i1 will be == to i2" it sounds like you already know the answer. From -128 to +127 the Integer objects are cached, so you get the same object for the same value. Greater than that, and you don't.
 
Manoj Kumar Jain
Ranch Hand
Posts: 198
Java Linux Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Matthew Brown for reply.

No I dont know the answer, I got this example from a book which was explaining that == operator compares for the reference value, not for the object value.
when I ran the same example with different object value I got the different result. Then I tried with different values combinations and got this query.
Now I got the answer that this is due to cached memory.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The == operator for references compare whether the reference values are equal--that is, whether both references refer to the same object, or both are null.

So if a == b is true, then both a and b refer to the same object, and if it's not, they don't.

So now you're wondering why for some Integers it's true and for others it's not. It's the same reason it's sometimes true for Strings and sometimes not. Namely, there is a constant pool.

For Strings the constant pool contains all the String literals from the source code, plus all Strings on which intern() was called, plus class names and other JVM bookkeping stuff. For Integer (and I think other integral wrapper classes) it contains, by default -128..127, so that whenever those values are used in autoboxing or with the valueOf() method, you'll get the one from the constant pool, rather than creating a new one.
 
Manoj Kumar Jain
Ranch Hand
Posts: 198
Java Linux Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cool, Thanks all for clarifying...
 
Campbell Ritchie
Marshal
Posts: 56592
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jeff Verdegan wrote: . . . For Integer (and I think other integral wrapper classes) it contains, by default -128..127, . . .
There are more details, as you said earlier, in the Java Language Specification (=JLS) (I can’t find the JLS 4th edition anywhere I can link to like that). The range -128..127 is described there as a minimum, so some implementations might cache Longs Integers Characters or Shorts beyond that range.
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!