About Question enthuware.ocajp.i.v7.2.1125 :
Moderator: admin
About Question enthuware.ocajp.i.v7.2.1125 :
i1 == i2 will return false because both are pointing to different object.
i1 will indeed == i2 since their values are between -128 and 127
i1 will indeed == i2 since their values are between -128 and 127
-
- Site Admin
- Posts: 10058
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocajp.i.v7.2.1125 :
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.
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.
-
- Posts: 28
- Joined: Wed Dec 04, 2013 7:57 pm
- Contact:
Re: About Question enthuware.ocajp.i.v7.2.1125 :
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?
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?
-
- Site Admin
- Posts: 10058
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocajp.i.v7.2.1125 :
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.
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.
-
- Posts: 1
- Joined: Thu Feb 23, 2017 4:25 pm
- Contact:
Re: About Question enthuware.ocajp.i.v7.2.1125 :
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
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
-
- Site Admin
- Posts: 10058
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocajp.i.v7.2.1125 :
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.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
-Paul.
If you like our products and services, please help us by posting your review here.
-
- Posts: 28
- Joined: Mon Sep 25, 2017 8:16 am
- Contact:
Re: About Question enthuware.ocajp.i.v7.2.1125 :
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?
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?
-
- Site Admin
- Posts: 10058
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocajp.i.v7.2.1125 :
== 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.
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.
-
- Posts: 19
- Joined: Sat Mar 25, 2017 5:38 am
- Contact:
Re: About Question enthuware.ocajp.i.v7.2.1125 :
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.
Which statement is true? Thanks.
-
- Site Admin
- Posts: 10058
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocajp.i.v7.2.1125 :
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.
-
- Posts: 19
- Joined: Sat Mar 25, 2017 5:38 am
- Contact:
Re: About Question enthuware.ocajp.i.v7.2.1125 :
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 wrote:Both the statements are correct. Why do you think there is a contradiction?
-
- Site Admin
- Posts: 10058
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocajp.i.v7.2.1125 :
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.
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.
-
- Site Admin
- Posts: 10058
- Joined: Fri Sep 10, 2010 9:26 pm
- Contact:
Re: About Question enthuware.ocajp.i.v7.2.1125 :
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.
-
- Posts: 19
- Joined: Sat Mar 25, 2017 5:38 am
- Contact:
Re: About Question enthuware.ocajp.i.v7.2.1125 :
Thanks Paul for a good explanation. I am looking forward to your book, hopefully soon .
Who is online
Users browsing this forum: Bing [Bot] and 103 guests