Equals doubt

[vidya sagar]

I found this question in mock exams

Given that b and c refer to instances of wrapper classes, which two statements are
true? (Choose two)
A. b.equals(b) returns true.
B. b.equals(c) returns the same result as b == c.
C. b.eqials(c) can return false even if c.equals(b) returns true.
D. b.equals(c) throws an exception if b and c are different wrapper types.
E. b.equals(c) returns false if the type of wrapper objects being compared are different.

According to me correct answer are A,B,E

But answer given is B, C

Can anyone plz explain... Why is it so???

[Corey McGlone]

Hmmm...Very interesting. Is there any explanation given for the answers? I'd be very interested to see what the explanation was.

Here's my thoughts on it:

A. b.equals(b) returns true.

This seems that it would be an accurate answer. Any object should be "equal" to itself. Heck, even if it didn't override .equals, it would logically equivalent from the default Object.equals method, which simply compares for object reference equality.

B. b.equals(c) returns the same result as b == c.

That's obviously not true. If you have 2 Integer objects that contain like values (both contain the number 12, for instance), the .equals method will return true but the == operator will return false as they are not actually the same object. They are two distinct objects that are logically equivalent.

C. b.eqials(c) can return false even if c.equals(b) returns true.

Hmmm. I can't think of a case in which that would be true. The only thing I can think of would be a case in which an Integer finds itself equivalent to a Float but not vice-versa. However, I know of no such rule so I'd have to say that this is a false statement.

D. b.equals(c) throws an exception if b and c are different wrapper types.

That's not true. It simply returns false.

E. b.equals(c) returns false if the type of wrapper objects being compared are different.

That's true.


So, in the end, I'd say that the correct answers are A and E.

If you can, find the explanation for their response and post them here. Perhaps I'm missing something entirely.

[levani dvalishvili]

I think there is something wrong with the question, either something is missing or its not specific enough
I does not say: if these two objects are same wraper class types? if they have same primitive value in it ? so without all theese info I think every answer is close to assuming which I think is not considered correct in test

correct answers should be E,...
[ April 15, 2005: Message edited by: levani dvalishvili ]

[Steven Bell]

I have to agree with Corey on this one. A and E.

As far as assumptions the only assumption I make is that by wrapper classes it means Integer, Byte, Float, Double, ect...

Here is the equals method from Integer to help clarify:

public boolean equals(Object obj) {
  if (obj instanceof Integer) {
    return value == ((Integer)obj).intValue();
  }
  return false;
}

'value' is the private int.

[Tony Morris]

The correct answer is A, E.
Yet another mock exam inadvertantly designed to mislead.
I'll just reiterate my lack of trust in mock exams, be it from a book, website or what not - I've seen too many screw ups from ill-informed authors.
(Perhaps this is my calling?)

[Kay Liew]

The answers were really really sick. B is definitely wrong. A and E were the right one. D is irrelevant. Not too sure about C, but I have a strong feeling C is not correct - it just do not sounds right especially the question is not specific enough for you to pick this option. There are plenty equal() questions are similar to this but in code forms. Make sure you check with the question erata. The author might have corrected it.

[Joe Sondow]

The reason C is incorrect is that all wrapper classes correctly implement the equals method, which means that they follow the second rule of the equals method contract:

It is symmetric: for any non-null reference values x and y, x.equals(y) should return true if and only if y.equals(x) returns true.

--Taken from the Java doc for java.lang.Object

[Mihai Alexe]

C. b.equals(c) can return false even if c.equals(b) returns true.

Well, let me clear things up about option C. If C were correct, the equals() implementation for wrapper classes would break the general contract for equals specified inside the Object class. It says there that the repation specified by equals must be a symmetric relation. That is, b.equals(c) is (better said, should be, and is in a correct and appropriate implementation) true if and only if c.equals(b) is true. This applies to any correct implementation of equals - and the one[s] for wrappers you can safely assume it's [are] correct [after all, the guys at Sun coded it [them] up ]
[ April 16, 2005: Message edited by: Mihai Alexe ]

[Tej Vattel]

I know everyone disagreed with B. But I spent all this time straining my brain has to how that could be true. I'm not sure I TOTALLY know what a Wrapper class is but I think Float is an example of one.

class round{
public static void main(String[] argv)
{
 
Float a = new Float(0.0f);
 
Float b = new Float(0.0f);
 
System.out.println(a.equals(b));//returns true
 
boolean c=(a==b);//returns false
System.out.println("" + c );
 
}
}

[Francisco Gonzalez]

As far as I can tell, A and E are the correct answers.

B can't be right since b==c is the basic equals implementation in Object class, which Wrapper classes override for a more meaningful comparison.

C also wrong, because it breaks the API contract of equals being symmetric, where both b.equals(c) and c.equals(b) should return true.

D is also wrong because Wrapper classes return false for Objects different from its type, they don't throw a exception for that.

Regards,
Francisco