• 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

discrepancy in comparison (==)

 
Ranch Hand
Posts: 198
Oracle Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Oracle Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Oracle Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Cool, Thanks all for clarifying...
 
Marshal
Posts: 79179
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic