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.
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.
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.
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 ]
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?)
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.
Unity can only be manifested by the Binary. Unity itself and the idea of Unity are already two.
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 ]
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.