Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Doubt on != and == when boxing and unboxing is used

 
Pratik D mehta
Ranch Hand
Posts: 121
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My question is when we use boxing in the below example

My doubt is when executing first loop of != should print "different objects" since both i1 and i2 refer to different objects.
I observed this code in SCJP Certification book for java6 by K & B
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
== and != work the same way for Integers. In both case, they will be unboxed and their int value will be compared.
See 15.21.1 Numerical Equality Operators == and != .
 
Jesper de Jong
Java Cowboy
Saloon Keeper
Posts: 15207
36
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Christophe Verré wrote:In both case, they will be unboxed and their int value will be compared.

I do not think this is true.

Did you try to compile and run the code? I tried your code (on Java 6 update 22, on Windows), and it prints "Different Objects", but it does not print "Same Objects".

In the if-statements in your code, it just compares the references. Since i1 and i2 refer to different Integer objects, you'll get "Different Objects", and not "Same Objects".

Unboxing will only be done when the compiler has a reason to do it - for example when you compare an Integer to an int variable, or to a literal numeric value. When comparing two Integer variables, the compiler can do the comparison by comparing references, so it doesn't have a reason to do unboxing.
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Unboxing will only be done when the compiler has a reason to do it - for example when you compare an Integer to an int variable, or to a literal numeric value.

You're right Jesper. I got knocked out by the boxing/unboxing concept
 
Joe carco
Ranch Hand
Posts: 82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A quick look at the source code of java.lang.Integer gives us the answer:



 
Pratik D mehta
Ranch Hand
Posts: 121
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes I am also running this program on "1.6.0_22"
Which i think means update 22
and I checked it by using command java -version , so what may be the issue .
 
Campbell Ritchie
Sheriff
Posts: 48418
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Try the System#identityHashCode method on those two Integer objects. There is caching of Integers, rather like Strings; it is mandatory for values in the range -128 ... 127 inclusive, but somewhere (I think the Java™ Language specification, But I can't find it in the index) it says the recommendation is for as many Integers as possible to be cached. It is possible that the newer JVMs are caching more Integers than -128..127. Your 1000 is a compile-time constant, so the compiler can recognise those are both the same value. The boxing creation of an Integer uses the valueOf() method, as you can see from this bytecode . . . and the valueOf link I posted tells you that frequently used values are cached.

That might be the cause of the confusion.

Anyway: avoid == and != on reference types.
 
Pratik D mehta
Ranch Hand
Posts: 121
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you Campbell
It was interesting to know this answer ,
There was a mistake from my side actually i compared Integer i1 = 10 and Integer i2 = 10 apart from book where it was given 1000
and so the value is been cached and hence != evaluated to false .
Yes and when i tried it for values 128 it wasn't cached , but for 127 it was .
So .........
Also I haven't read the JLS and thankyou very much for this answer it cleared the doubt to a deeper extent .

 
Seetharaman Venkatasamy
Ranch Hand
Posts: 5575
Eclipse IDE Java Windows XP
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In contrast to == and !==, operators such as <, >, + are unbox the wrapper objects before performing their operation.
 
Martin Vajsar
Sheriff
Pie
Posts: 3751
62
Chrome Netbeans IDE Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Seetharaman Venkatasamy wrote:In contrast to == and !==, operators such as <, >, + are unbox the wrapper objects before performing their operation.


Yes. It is done this way because only != and == can be applied to instances. The other operators must operate on a numerical value, which can be obtained only by unboxing.

The correct test to see whether == and != on Integers performs unboxing or not must make sure the two instances are different, eg. by calling a constructor explicitly (this is, by the way, generally discouraged, because the caching mechanism is circumvented):
 
Pratik D mehta
Ranch Hand
Posts: 121
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is good to use the equals method to compare rather than == to compare the contents .

yes there is no unboxing .

But only if we initialize it without new and if the values are between -128 and 127 than the values are cached so == yields "Equal"
Otherwise
== and != compare the references of Objects for wrappers.
 
Campbell Ritchie
Sheriff
Posts: 48418
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pratik D mehta wrote: . . . i compared Integer i1 = 10 and Integer i2 = 10 . . .
You would have had the explanation much faster if you had posted the code you actually used.
 
Campbell Ritchie
Sheriff
Posts: 48418
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pratik D mehta wrote:Thank you Campbell . . .
You're welcome
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic