About Question enthuware.ocajp.i.v7.2.1125 :

Help and support on OCA OCP Java Programmer Certification Questions
1Z0-808, 1Z0-809, 1Z0-815, 1Z0-816, 1Z0-817

Moderator: admin

Post Reply
ETS User

About Question enthuware.ocajp.i.v7.2.1125 :

Post by ETS User »

i1 == i2 will return false because both are pointing to different object.

i1 will indeed == i2 since their values are between -128 and 127

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1125 :

Post by admin »

What you are saying applies only when you are comparing objects created because of auto-boxing. For example:
Integer i1 = 1;
Integer i2 = 1;
System.out.println(i1 == i2); //this will print true.

But in the question, we are doing
i2 = new Integer(1); //this is not the same object as the one that is assigned due to auto-boxing.

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

tn1408
Posts: 28
Joined: Wed Dec 04, 2013 7:57 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1125 :

Post by tn1408 »

Why is
Integer i1 = 1;
Integer i2 = 1;
System.out.println(i1 == i2); //this will print true.

but
Integer i1 = new Integer(1);
Integer i2 = new Integer(1);
System.out.println(i1 == i2); will return false.

In the first case, what are actually being compared?

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1125 :

Post by admin »

In both the cases Integer objects are being compared. However, in the first case, because of auto-boxing, the same Integer object is reused on both the lines. That is why == produces true. While in the second case, two different Integer objects (containing 1) are being used, so == produces false.

You may want to read this helpful discussion here: http://stackoverflow.com/questions/1776 ... autoboxing

HTH,
Paul.
If you like our products and services, please help us by posting your review here.

stupidQuest
Posts: 1
Joined: Thu Feb 23, 2017 4:25 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1125 :

Post by stupidQuest »

If the object "b1" will not compile for Option 3, why on earth would it all of a sudden work for Option 6 and return false? Could someone please fix questions like this as I see comments from 2010 it has been 7 years sine update. (yes, I have the latest!)

Byte b1 = 1; //invalid therefore
//i1 == b1 will not compile and i1.equals(b1) will not compile
Byte b1 = (Byte) 1; //correct
Byte b1 = (byte) 1; //correct with autobox

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1125 :

Post by admin »

stupidQuest wrote:If the object "b1" will not compile for Option 3, why on earth would it all of a sudden work for Option 6 and return false? Could someone please fix questions like this as I see comments from 2010 it has been 7 years sine update. (yes, I have the latest!)

Byte b1 = 1; //invalid therefore
//i1 == b1 will not compile and i1.equals(b1) will not compile
Byte b1 = (Byte) 1; //correct
Byte b1 = (byte) 1; //correct with autobox
StupidQuest, it hasn't been fixed for 7 years because there is nothing wrong with it :) The given answer is correct. Byte b1 = 1; is not invalid. i1.equals(b1) will also compile fine and return false at run time. You might want to try it out.

-Paul.
If you like our products and services, please help us by posting your review here.

JuergGogo
Posts: 28
Joined: Mon Sep 25, 2017 8:16 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1125 :

Post by JuergGogo »

I tried it out.

i1 == b1; doesn't compile (incomparable types: java.lang.Integer and java.lang.Byte)
i1.equals(b1); does compile and the result is false

In both cases the compiler has the same information: i1 / b1 are of different types.
So the reaction of the compiler should be the same. But it isn't. Why not?

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1125 :

Post by admin »

== compares object references. The compiler knows that b1 and i1 can never point to objects of same kind (one is Byte and another is Integer) and therefore i1 and b1 can never point to the same object and so it rejects the statement as invalid.

equals method is executed at runtime. The compiler has no role to play in how the equals method performs the comparison. Thus, the compiler has no choice but to accept the statement as valid.
If you like our products and services, please help us by posting your review here.

mjmsausava
Posts: 19
Joined: Sat Mar 25, 2017 5:38 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1125 :

Post by mjmsausava »

The answer explanation says "i1 == b1 will not even compile because type of i1 and b1 references are classes that are not in the same class hierarchy. So == knows at compile time itself that they can't point to the same object." However I read in wikipedia that "The Byte , Short , Integer , Long , Float , and Double wrapper classes are all subclasses of the Number class."

Which statement is true? Thanks.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1125 :

Post by admin »

Both the statements are correct. Why do you think there is a contradiction?
If you like our products and services, please help us by posting your review here.

mjmsausava
Posts: 19
Joined: Sat Mar 25, 2017 5:38 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1125 :

Post by mjmsausava »

admin wrote:Both the statements are correct. Why do you think there is a contradiction?
May be I wrong but I thought if all the wrapper classes are subclasses of Number class, then they may be considered in the same hierarchy. Therefor the compiler may know the objects of the wrapper class (or == in this case ) possibly can point to the same object.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1125 :

Post by admin »

What you mean by same hierarchy? Byte, Double, Float, Integer, Long, Short do extend Number class. So Byte and Number (and Double and Number and Float and Number and so on) do have a parent child relationship but there is no relation between Byte and Double or Byte and Integer.


Thus, if you have a variable of class Number, that variable can certainly point to an object of class Byte, Double, Float, Integer, Long, or Short.
But if you have a variable of class Byte, why do you think it should be able to point to an object of class Double, or Float, or Integer etc?

Think of it like this - Dog, Cat, Cow, and Goat are all Animals. That means a Goat is-a Animal, but does that mean a Goat is a Dog? Of course, not.
Therefore, Animal a = new Goat(); will work at compile time as well as run time because a Goat is certainly an Animal.
Goat g = (Goat) a; will also work at compile time because an Animal could be (not necessarily but possibly) a Goat. So the compiler is happy. The JVM at run time will check if a really refers to an object of class Goat. If it does, then the JVM will be happy as well other it will throw a ClassCastException.

But -

Goat g = (Dot) d; will never even compile, because a Dog can never be a Goat. The compiler will therefore refuse to compile this statement.

Paul.
If you like our products and services, please help us by posting your review here.

admin
Site Admin
Posts: 10036
Joined: Fri Sep 10, 2010 9:26 pm
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1125 :

Post by admin »

BTW, you should go through a good book to understand this concept very clearly before attempting mock exams.
If you like our products and services, please help us by posting your review here.

mjmsausava
Posts: 19
Joined: Sat Mar 25, 2017 5:38 am
Contact:

Re: About Question enthuware.ocajp.i.v7.2.1125 :

Post by mjmsausava »

Thanks Paul for a good explanation. I am looking forward to your book, hopefully soon ;).

Post Reply

Who is online

Users browsing this forum: No registered users and 43 guests