• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

doubt with wrapper class code

 
Vishal Hegde
Ranch Hand
Posts: 1077
Java Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Integer i1=1000;
Integer i2=1000;
if(i1!=i2)
{
System.out.println("differnt object");
}
if(i1.equals(i2))
{
System.out.println("meaningfully equal")
}

how are both if statements runing???
 
Rob Spoor
Sheriff
Pie
Posts: 20372
44
Chrome Eclipse IDE Java Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
They are equal because they both represent the number 100. They are both different objects though, since autoboxing only uses cached values for -128 to 127. Everything outside that range will actually return a new Integer object.
 
Campbell Ritchie
Sheriff
Pie
Posts: 47229
52
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, if you look in the Java™ Language Specification it is rather vague about which values are cached. It suggests -128..127 is a minimum and some applications might cache a larger range.
 
Embla Tingeling
Ranch Hand
Posts: 237
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob Prime wrote:They are equal because they both represent the number 100.


1000 is represented by 100? I wasn't aware of that.

Would you please point at the relevant section in the JLS.
 
Paul Sturrock
Bartender
Posts: 10336
Eclipse IDE Hibernate Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I suspect this is a typo.
 
Campbell Ritchie
Sheriff
Pie
Posts: 47229
52
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Embla Tingeling wrote:Would you please point at the relevant section in the JLS.
It must be section 983459658757348739.
 
Francisco Montes
Ranch Hand
Posts: 30
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I ran the code and sure enough both ifs expressions resulted true as expected: they are both completely different objects but their values are meaningfully equal.

Taking into account Rob´s reply, if you modify 1000 with 100 or some low enough value then both Integer references will point to the same object in memory. I am not sure either if this -127...128 range of "cached values" is the only valid one for all JVMs, but it is certainly the range used on my local machine.
 
Vishal Hegde
Ranch Hand
Posts: 1077
Java Windows
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
what are cached values are they same as predefined values?? and what is JLS??
 
Campbell Ritchie
Sheriff
Pie
Posts: 47229
52
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JLS is the Java™ Language Specification; I posted a link to it yesterday. You will have to look about cached values in that link.

I don't think it actually says what happens, whether the cached values are predetermined rather like eager instantiation, nor whether they are set up at the time they are used, like a sort of lazy instantiation.
 
salvin francis
Bartender
Pie
Posts: 1212
10
Eclipse IDE Google Web Toolkit Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I would suggest not to use "==" for Objects
use equals method.

As i understand the 127 range of caching may be done for performance reasons,
you may be suprised that sometimes even two diff string objects come out as equal,

In fact I once raised this Question to one of my professor in college that she should have used


instead of

and guess what I got back in reply:
When I ran it, it worked fine





 
Campbell Ritchie
Sheriff
Pie
Posts: 47229
52
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
salvin francis wrote: . . . When I ran it, it worked fine . . .
When I did the "Advanced Java" module, one of the people had some Strings to compare with the ==. In C# that operator is overloaded for Strings, so that works in C#.There were many Strings to compare, and of course it worked . . . because they were assigned from String literals. Then after serializing and de-serializing the whole object, all the Strings which had been referring to literals didn't any more.


So you can get things which work when you use == on Strings, and can break mysteriously later on.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic