Equality

source : http://enigma.vm.bytemark.co.uk/Inquisition-0.14/inquisition.jnlp
thats a free mock exam software, thanks to the author, its good..

question goes like this :
given object(s) a and b of the same class, and if equals() and hashcode() are implemented correctly for that class, fill in the blanks to indicate which statements are
1. can be true for some implementations, but not for others,
2. are always true,
3. and are never true

given that... a == b then, a.equals(b) ________________

given that... a != b then, a.equals(b) ________________

given that... a.equals(b) then, a == b ________________

given that... !a.equals(b) then, a == b ________________

_____________________________________________

fill blanks with
"is never true" or
"can be true" or
"is always true"

could someone solve this with a good explanation for me please??

could someone solve this with a good explanation for me please??

Well, what do you think the answers are? It is better to try it out yourself first...

Henry

1. hi Mr Wong

did you feel I am asking too many silly questions today ? thats because I am taking the certification on monday, and right now, I am not feeling very confident .. So i like to have clearer explanations and satisfying answers from people who really know

2. I know the answers, I saw them in the mentioned software itself.. they are like for 1. Always true ( I am convinced with that) for 2nd and 3rd , its can be true, and last, its never true..
I want to know, what is this real difference between == and equals.. According to my knowledge, == would check the reference variables bit by bit, so if both referred same object, then they give true.. but i am confused with 3rd one.. how is the answer "can be true" possible if a.equals(b) is true.. shouldn't it be always true? And for 4th one, the answer says never true..fine with that too..
so my confusion is only with 3rd one..

but i am confused with 3rd one.. how is the answer "can be true" possible if a.equals(b) is true.. shouldn't it be always true?

Think about it.... Let's say you have...

String a = "hello";
String b = new String(a);

is a.equals(b) true? is a==b true?

Henry

thanks Mr. Henry, ya.. you are right.. I am feeling like crucifying myself now... how do i delete this thread from here please.?

Shrinath M Aithal wrote:thanks Mr. Henry, ya.. you are right.. I am feeling like crucifying myself now... how do i delete this thread from here please.?

Please don't. Topics may help other users in the future. ie... Others can learn from your mistakes.

Henry

ok, coming back to equals(),

in a thread (http://www.coderanch.com/t/451227/Programmer-Certification-SCJP/certification/String-manipulation)

I learnt that , given..

sb1.equals(sb2) returns false.. I know both are different objects, now, but aren't they same internally? shouldn't .equals() be returning true, as in if I tried comparing two Integer or String objects?

shouldn't .equals() be returning true, as in if I tried comparing two Integer or String objects?

The designers of the StringBuffer class never bothered to override the equals() method. It is using the equals() method that is inherited from the Object class.

Henry

you mean to say "it is useless to type equals, rather use ==" because they both do same job ?

so how many other classes out there are really like this? I mean, if StringBuffer doesn't know how to check deeply enough, then how many other classes are doing the same way?
if asked in exam, how can i be sure, it does deep compare or not?

Shrinath M Aithal wrote:you mean to say "it is useless to type equals, rather use ==" because they both do same job ?

so how many other classes out there are really like this? I mean, if StringBuffer doesn't know how to check deeply enough, then how many other classes are doing the same way?
if asked in exam, how can i be sure, it does deep compare or not?

No class is required to override equals(), so it all comes down to reading the Javadocs. I would just make a list of all the classes you've come across while studying and look them up.

OK, lets cut to the chase here and let me try to answer your question 3.

.. but i am confused with 3rd one.. how is the answer "can be true" possible if a.equals(b) is true.. shouldn't it be always true?

given that... a.equals(b) then, a == b ________________

the answer for the above is: "can be true"

the reason for the above answer is because you can have a.equals(b) true WHILE a==b is false. the below example illustrate this:
String a = new String("SCJP");
String b = new String("SCJP');

Here you have TWO String objects and each one of them has the literal SCJP in it, so the content is the same BUT the references a and b are pointing to distinct String objects.

Hope this helps,
Cheers!!

thanks mo jay

got it.. everyone here helped greately..

Well, if the "equals contract" is fulfilled then two distinct objects of the same type can be meaningfully "equal" (that is... .equals() is true) while NOT being the same identical objects (that is..... == is false.)

== tests to see if they are the same identical object.

.equals() tests to see if they are "meaningfully equal". Meaningfully equal depends on the implementation of the .equals() method.