aspose file tools*
The moose likes Beginning Java and the fly likes Doubt on != and == when boxing and unboxing is used Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Doubt on != and == when boxing and unboxing is used" Watch "Doubt on != and == when boxing and unboxing is used" New topic
Author

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

Pratik D mehta
Ranch Hand

Joined: Jul 29, 2010
Posts: 121

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

Understanding is Everything - Peter Lord
Christophe Verré
Sheriff

Joined: Nov 24, 2005
Posts: 14687
    
  16

== 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 != .


[My Blog]
All roads lead to JavaRanch
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 13884
    
  10

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.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Christophe Verré
Sheriff

Joined: Nov 24, 2005
Posts: 14687
    
  16

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

Joined: Apr 14, 2009
Posts: 82
A quick look at the source code of java.lang.Integer gives us the answer:



Pratik D mehta
Ranch Hand

Joined: Jul 29, 2010
Posts: 121

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

Joined: Oct 13, 2005
Posts: 36590
    
  16
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

Joined: Jul 29, 2010
Posts: 121

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

Joined: Jan 28, 2008
Posts: 5575

In contrast to == and !==, operators such as <, >, + are unbox the wrapper objects before performing their operation.
Martin Vajsar
Sheriff

Joined: Aug 22, 2010
Posts: 3454
    
  47

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

Joined: Jul 29, 2010
Posts: 121

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

Joined: Oct 13, 2005
Posts: 36590
    
  16
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

Joined: Oct 13, 2005
Posts: 36590
    
  16
Pratik D mehta wrote:Thank you Campbell . . .
You're welcome
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Doubt on != and == when boxing and unboxing is used
 
Similar Threads
Doubt in Wrapper
difference between != or ==
Small doubt in Boxing & == & equals()
Doubt in equals and == . Please help.
Boxing, == and equals