Win a copy of Mastering Corda: Blockchain for Java Developers this week in the Cloud/Virtualization forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Jj Roberts
  • Carey Brown
Bartenders:
  • salvin francis
  • Frits Walraven
  • Piet Souris

Boxing confusion

 
Ranch Hand
Posts: 92
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
author
Posts: 23893
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
 
John McParland
Ranch Hand
Posts: 92
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Henry. Yes it's when autoboxing has been used that == and != stop working;

 
Ranch Hand
Posts: 1880
Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This article will be helpful:
http://today.java.net/pub/a/today/2005/03/24/autoboxing.html
 
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Comparison Value is Restricted To 127

 
Ranch Hand
Posts: 95
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

 
Bob Wheeler
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Posts: 95
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 317
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 carry this gun in case a vending machine doesn't give me my fritos. This gun and this tiny ad:
the value of filler advertising in 2020
https://coderanch.com/t/730886/filler-advertising
reply
    Bookmark Topic Watch Topic
  • New Topic