• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

autoboxing:Compare Long with int

 
Jason Attin
Ranch Hand
Posts: 232
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
HI guys, I am not sure I understand this example, from Glenn, Mitchell. OCAJP Oracle Certified Associate Java SE 8 Programmer Practice Exams (Kindle Locations 5115-5120). Enthuware. Kindle Edition.
Consider the following lines of code:

Which of the following options are valid? Select 3 options
A.
B.
C.
D.
E.

Correct answers are C,D,E.
Now with regard to E, the explanation says
Due to auto-boxing int 42 is converted into an Integer object containing 42. So this is valid. It will return false though because ln is a Long and 42 is boxed into an Integer.

What I'm not entirely sure about is why 42 is boxed to an Integer object. Is that because equals() requires two objects?
Let's take a different scenario, just so I understand:
this presumably will return true because ln is auto-unboxed to a long and then the integer 42 is promoted to a long, correct? This comparison is possible because "==" doesn't require both the operands to be objects and in fact it will not compile if they were both objects.


 
Henry Wong
author
Marshal
Pie
Posts: 22124
88
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jason Attin wrote:Now with regard to E, the explanation says
Due to auto-boxing int 42 is converted into an Integer object containing 42. So this is valid. It will return false though because ln is a Long and 42 is boxed into an Integer.

What I'm not entirely sure about is why 42 is boxed to an Integer object. Is that because equals() requires two objects?


42 gets boxed to an Integer object because 42 is an int literal. As for why it happens... it is because there isn't a equals() method that takes an int parameter, so it has to box the int in order to resolve the equals() method.

Jason Attin wrote:
Let's take a different scenario, just so I understand:
this presumably will return true because ln is auto-unboxed to a long and then the integer 42 is promoted to a long, correct? This comparison is possible because "==" doesn't require both the operands to be objects and in fact it will not compile if they were both objects.


Correct. If one side of equality operator is not an object, then unboxing will be used to get both sides to be primitive types.

Henry
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You'll find everything you need to know about using == operator on wrapper classes (and much more) in this excellent topic (with tons of code examples).
 
Lalit Sahu
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
C,D,E are correct. "==" use to compare objects reference addresss which mean it compare for reference address of two object and return true if both object pointing towards same address  while ".equals" use to compare value of same type of object .
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic