File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Boxing confusion Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Boxing confusion" Watch "Boxing confusion" New topic
Author

Boxing confusion

John McParland
Ranch Hand

Joined: May 11, 2009
Posts: 92

Hi all,

so in the two minute drill for Boxing (chapter 3, objective 3.1) says;

"Using == with wrappers created through boxing is tricky; those with the same small values (typically lower than 127), will be ==, larger values will not be ==."

So... what does this mean? Seemingly you simply cannot depend on == working with an Object created through boxing? I tried an experiment;



The output is;



which implies to me that comparing wrappers and primitives, regardless of whether boxing takes place, always works with == and !=.

Am I right or have I misunderstood the objective?

Passed: SCJP 6 (90%), SCJD 6
Other: Spring training, extensive Swing experience
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

which implies to me that comparing wrappers and primitives, regardless of whether boxing takes place, always works with == and !=.


Whenever you compare a wrapper with a primative, the wrapper object will always be unboxed for the comparison -- which is why all the conditionals worked in your example.

Am I right or have I misunderstood the objective?


I believe the quotes were referring to instance comparison of two wrappers that have been autoboxed -- and not a comparison between a wrapper and a primative. As there isn't much "tricky" about such a comparison.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
John McParland
Ranch Hand

Joined: May 11, 2009
Posts: 92

Thanks Henry. Yes it's when autoboxing has been used that == and != stop working;

Krishna Srinivasan
Ranch Hand

Joined: Jul 28, 2003
Posts: 1844

This article will be helpful:
http://today.java.net/pub/a/today/2005/03/24/autoboxing.html


Krishna Srinivasan
Spring Tutorials, OCAJP Mock Questions, 400+ OCPJP Mock Questions
Jacob Sonia
Ranch Hand

Joined: Jun 28, 2009
Posts: 174
Hi, when i read this i understood this:

if we say
Integer i = 127;
Integer j = 127;
if(i == j) //returns true;
Integer i = 129;
Integer j = 129;
if(i == j) // returns false;
but it will not work here because using new always create a new object, so == starts comparing references now
Integer i = new Integer(127);
Integer j = new Integer(127);
if(i == j) //returns false

Correct me if i am wrong
Bob Wheeler
Ranch Hand

Joined: Apr 24, 2009
Posts: 317
Jacob Sonia wrote:Hi, when i read this i understood this:

if we say
Integer i = 127;
Integer j = 127;
if(i == j) //returns true;
Integer i = 129;
Integer j = 129;
if(i == j) // returns false;
but it will not work here because using new always create a new object, so == starts comparing references now
Integer i = new Integer(127);
Integer j = new Integer(127);
if(i == j) //returns false

Correct me if i am wrong

"==" ALWAYS compares objects, NEVER references.
So, if you uses NEW, a new object is created, which results in "false" using "==".
But if you use autoboxing with a value between -128 and +127, the object is ALREADY
there (before autoboxing). So all references point to the same object resulting into a true output using "==".

cheers
Bob


SCJP 6 - SCJD - SCWCD 5 - SCBCD 5
JavaEnterpriseEditionFaq - TomcatFaq
sandip sangale
Greenhorn

Joined: Jun 22, 2009
Posts: 15
Comparison Value is Restricted To 127

AmitKumar Jain
Ranch Hand

Joined: Jun 13, 2005
Posts: 95
Hi Bob,

I disagree slightly. Though you are correct, the statement requires correction.

== in case of references, checks whether the references point to the same object.
[ == in no way can compare objects , it just compares the references , which are
nothing but object handles ]

Amit


SCJP 1.4 : 91%
SCWCD 1.4 : 95%
SCBCD 1.3 : 95%
SCJP 6 Upgrade : 95%
Next SCBCD 1.5
Man is not finished when he is defeated. He is finished when he quits.
Bob Wheeler
Ranch Hand

Joined: Apr 24, 2009
Posts: 317
AmitKumar Jain wrote:Hi Bob,

I disagree slightly. Though you are correct, the statement requires correction.

== in case of references, checks whether the references point to the same object.
[ == in no way can compare objects , it just compares the references , which are
nothing but object handles ]

Amit

Hi Amit,

actually I meant the same. If you compare references, you compare the objects where they point to (or the memory they point to).
For me two different references are different even if they point to the same object. So what is meant by different ? ...
I leave it here, as we are in the SCJP forum.

cheers
Bob


AmitKumar Jain
Ranch Hand

Joined: Jun 13, 2005
Posts: 95
Hi Bob,

" For me two different references are different even if they point to the same object...."

Java always talks of references having a value which is a handle to an Object.
[ although the value is not known to us ]
Hence, when two references refer to the same Object, they are considered having the same value.

Even when we talk of Pass By Reference in method invocations, we say that copy(value) of
the reference is passed. Hence it is often said, "In Java, references are passed by value".

Amit.
Bob Wheeler
Ranch Hand

Joined: Apr 24, 2009
Posts: 317
Hi Amit,

OK, now I get the difference between us. The JVM doesn't really compare the objects to which the references "point",
it compares what is stored in the references. So, if two references "point" to the same object they have the same value
stored. Then, there is no need to compare the object anymore.

Thanks for the insight.
cheers
Bob
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Boxing confusion