• Post Reply Bookmark Topic Watch Topic
  • New Topic

A question on how == works along with autoboxing  RSS feed

 
Kumar Raja
Ranch Hand
Posts: 550
2
Hibernate Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello All,

I have this simple program


The output is true, true, false, false

Few questions based on this output

1) l1 and l2 both are two different objects (but may have same value), then how come l1==l2 returns true.
2) l1 == 10, may be true because in this case, I'm assuming that l1 is autoboxed to long primitive and the values compared. Is this correct ? or they are equal due to some other reason
3) When l1 == l2 is true, then why not l1 == l3 and l2 == l3. Again, returning false in this case makes sense because l1 and l3 are two different objects. But why was this not applicable to case 1.

What is the subtle difference in each of these ?


 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kumar Raja wrote:Hello All,

I have this simple program


The output is true, true, false, false

Few questions based on this output

1) l1 and l2 both are two different objects (but may have same value), then how come l1==l2 returns true.
2) l1 == 10, may be true because in this case, I'm assuming that l1 is autoboxed to long primitive and the values compared. Is this correct ? or they are equal due to some other reason

See: http://www.coderanch.com/how-to/java/CachedObjects
The values are cached, the link explains when this occurs.

Kumar Raja wrote:3) When l1 == l2 is true, then why not l1 == l3 and l2 == l3. Again, returning false in this case makes sense because l1 and l3 are two different objects. But why was this not applicable to case 1.

You never compared l1 to l3 or l2 to l3, you compared l1 to 13 and l2 to 13 (read el one to thirteen and el two to thirteen). Thirteen is not the same as Ten (the value in l1 and l2) and so false is the result. This, by the way, is one of the problems of using simple variable names. If you had used 'firstLong' 'secondLong' 'thirdLong' as your variable names you wouldn't have made the mistake!
 
Marc Cracco
Ranch Hand
Posts: 80
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kumar Raja wrote:Hello All,

I have this simple program


The output is true, true, false, false

Few questions based on this output

1) l1 and l2 both are two different objects (but may have same value), then how come l1==l2 returns true.
2) l1 == 10, may be true because in this case, I'm assuming that l1 is autoboxed to long primitive and the values compared. Is this correct ? or they are equal due to some other reason
3) When l1 == l2 is true, then why not l1 == l3 and l2 == l3. Again, returning false in this case makes sense because l1 and l3 are two different objects. But why was this not applicable to case 1.

What is the subtle difference in each of these ?




You don't check the following:
then why not l1 == l3 and l2 == l3.
so I'm not sure what you're referencing. Also using numbers in variable name is not good practice. Especially here where you're using l2 and 12, they can be easily mistaken while reading.
use var names like longOne and longTwo
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kumar Raja wrote:
2) l1 == 10, may be true because in this case, I'm assuming that l1 is autoboxed to long primitive and the values compared. Is this correct ? or they are equal due to some other reason


Yes, when comparing a Long object to a primitive long, Java will unbox the Long object, and do a comparison of the values.

Henry
 
Kumar Raja
Ranch Hand
Posts: 550
2
Hibernate Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marc and Steve,

Thanks for pointing out my mistake. I agree, I got confused between l3 and 13.

I changed the variable names to first, second, third

so the code now looks like




and now I see all true.

Steve, thanks for the link on Cached Objects and understand that when used valueOf() function while creating Long, it will check if the value is in the range of -128 to 127 and assigns from the cache. Otherwise creates a new object.

However, is the above true even in the case, when valueOf() is not used. I mean to ask

if Long first = 10L; and Long first = Long.valueOf(10L); check if there is a value already in cache and assigns this. Because

Long first = 10L;
Long second = 10L;
System.out.println(first==second); //true

Long first = Long.valueOf(10L);
Long second = Long.valueOf(10L);
System.out.println(first==second); //true

Thanks to Steve,Henry and Marc
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kumar Raja wrote:However, is the above true even in the case, when valueOf() is not used. I mean to ask

if Long first = 10L; and Long first = Long.valueOf(10L); check if there is a value already in cache and assigns this. Because

Long first = 10L;
Long second = 10L;
System.out.println(first==second); //true

Long first = Long.valueOf(10L);
Long second = Long.valueOf(10L);
System.out.println(first==second); //true

I thought this was mentioned in the FAQ link, but it is only hinted at and not explicitly said. Autoboxing does essentially (exactly?) the same thing as valueOf(). It uses the cache. So if you use autoboxing or valueOf() you will get results from the cache. But when you use the new operator to create a wrapper class (like Long forth = new Long(10L);) it does not use the cache, and so would get you a new and unique object. All this is purely academic, of course, since you should AvoidTheEqualityOperator (<- link) whenever possible (because you really don't know how the Long was created, what range of Longs are cached, etc... == may produce inconsistently while .equals() always works as expected).
 
Campbell Ritchie
Marshal
Posts: 56598
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The Java Language Specification does not specify whether boxed Longs are cached; it seems to recommend caching however.
 
Kumar Raja
Ranch Hand
Posts: 550
2
Hibernate Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you all
 
Campbell Ritchie
Marshal
Posts: 56598
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're welcome
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!