hashCode Question

I saw this question on a mock exam, but I don't always trust their answers. I hear that hashCode questions are big on the certification exam, so a thorough explanation of this question would
be helpful.
Which two statements are true regarding the return values of properly written hashCode and equals methods returned from two instances of the same class? (Choose two)
A. If the hashCode values are the same, the objects might be equal.
B. If the hashCode values are the same, the objects must be equal.
C. If the hashCode values are different, the objects might be equal.
D. If the hashCode values are different, the objects must be equal.

Well, I'm not agreeing with this question, but I might be off -- I cannot find two true statements here, only one.

Which two statements are true regarding the return values of properly written hashCode and equals methods returned from two instances of the same class? (Choose two)
A. If the hashCode values are the same, the objects might be equal.
TRUE. There is no guarantee that if the hashCode values are the same, the objects will be equal. You cannot tell from the hashCode whether two objects are equal -- the more inefficient the hashCode algorithm, the more likely it is that unequal objects will have the same hashcodes. (for example, if you make a class with a hashCode method that simply returns 42. That's legal, and can even be considered "appropriate" in terms of meeting the contract for equals and hashcode, even though it would be wildly inefficient).
B. If the hashCode values are the same, the objects must be equal.
FALSE -- for the reasons mentioned above.
C. If the hashCode values are different, the objects might be equal.
FALSE -- if the the objects are equal then the hashCode values MUST be the same.
D. If the hashCode values are different, the objects must be equal.
Obviously FALSE.
Bottom line: If the objects are equal, the hashCodes MUST be equal. It's OK for unequal objects to have the same (or different) hashCodes, but it is NEVER OK for two equal objects to have different hashCodes.
So... where was that question from? If it's from Sun, I'll have to fix it!

cheers,
Kathy

As Kathy explained in details, only option A is correct. You may want to have a look at this articleand see if it useful.
HTH,
- Manish

Very useful article!
What does this mean:

The equals method must not provide equality comparison with any built in Java class, as it would result in the violation of the symmetry requirement stated in the general contract of the equals method.

Thanks.
Deepa
[ November 12, 2002: Message edited by: Deepa Vinod ]

It means that if b.equals(a), then a.equals(b) and vice versa.
Suppose your class's equals() method returns true when its argument is a built-in Java class such as String or Integer. This violates symmetry because the built-in class's equals() method will always return false when its argument is a member of your class.

hi,Ron
sorry,I couldn't understand that words.
can you give some examples?
thanx.

An object from any class you design might equal an object instanced from a built-in class, based on the way you write the equals() method for your class. However, the built-in class' equals() method will certainly never find equality with your class. This is a violation of one property of equality, symmetry, which is a requirement.
In code terms:

Symmetry is the property of equality that says one object can equal another only if both objects would agree that they are equal.
Another required property, transitivity, extends from this. If object a is equal to object b, and if object b is equal to object c, then object a must be equal to object c. Any equals() method that does not pass this test is also invalid.

I used this question to dig into the API documentation on the String class and Object class especially as it pertains to the equals() methods.
In class MikeString, I have made it explicit that we are extending the Object class, although it would have done so by default.
So when we call "if (mstr.equals(str)) " we are using the equals() method of the Object class, which I did NOT override.

public class MikeString extends Object {
MikeString (String inStr) {
System.out.println(inStr + " named MikeString object instantiated");
}
//  equals() method for MikeString inherited from Object class
//  public boolean equals(Object obj) {
  // see java source code for implementation details
//  }
/* The equals method for class Object implements the most discriminating
   possible equivalence relation on objects; that is, for any reference
       values x and y, this method returns true if and only if x and y refer
       to the same object (x==y has the value true).
       */
public static void main (String [] args) {
String str = new String("bleck");
MikeString mstr = new MikeString("bleck");
if (mstr.equals(str)) { // resolves to true if MikeString equals() code permits it
System.out.println("mstr.equals(str) is true");
}else {
System.out.println("mstr.equals(str) is FALSE");
}
if(str.equals(mstr)) {// will never resolve to true...
System.out.println("str.equals(mstr) is true");
}else {
System.out.println("str.equals(mstr) is FALSE");
}
}
}
/* output
C:\BIN>javac MikeString.java
C:\BIN>java MikeString
bleck named MikeString object instantiated
mstr.equals(str) is FALSE
str.equals(mstr) is FALSE
C:\BIN>
*/

When we call "if(str.equals(mstr))" we are using the equals () of the String class:

equals
public boolean equals(Object anObject)
Compares this string to the specified object. The result is true if and only if the argument is not null and is
a String object that represents the same sequence of characters as this object.
Overrides:
equals in class Object

In our example, mstr is NOT a String object, it is a new, user defined type (object).
Hope this helps.

oh, one other thing:
if you add a couple of println statements like this -

you'll see you have different object types:
MikeString@601bb1
bleck

Originally posted by Mike Cutter:
I saw this question on a mock exam, but I don't always trust their answers. I hear that hashCode questions are big on the certification exam, so a thorough explanation of this question would
be helpful.
Which two statements are true regarding the return values of properly written hashCode and equals methods returned from two instances of the same class? (Choose two)
A. If the hashCode values are the same, the objects might be equal.
B. If the hashCode values are the same, the objects must be equal.
C. If the hashCode values are different, the objects might be equal.
D. If the hashCode values are different, the objects must be equal.

According to the API for java.lang.Object equals() method:

Note that it is generally necessary to override the hashCode method whenever this method is overridden, so as to maintain the general
contract for the hashCode method, which states that equal objects must have equal hash codes.

Rules out C & D immediately.
B - as Kathy said above, you can override the hashcode method to return same value all the time, so you cannot say "the objects must be equal."

So A would be correct.

j2sdk1.4.1/docs/api/java/lang/Object.html#hashCode()
java.lang.Object
public int hashCode()

The general contract of hashCode is:

Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified. This integer need not remain consistent from one execution of an application to another execution of the same application.

If two objects are equal according to the equals(Object) method, then calling the hashCode method on each of the two objects must produce the same integer result.

It is not required that if two objects are unequal according to the equals(java.lang.Object) method, then calling the hashCode method on each of the two objects must produce distinct integer results. However, the programmer should be aware that producing distinct integer results for unequal objects may improve the performance of hashtables.

As per David post we need a option
E) If the hashCode values are the same, the objects might NOT be equal.
so now Ans as per me are A & E.
[I was wrong in my earlier post

]
[ November 27, 2002: Message edited by: Ravish Kumar ]

Manish , article is really superb..
Now I think, when I get newsletter, its better to put 1-2 hr on it.
Thanks a lot.. after a long time got a good article on the simplest class Object and its most common methods.
Keep it up

that Hashcode question (in the original post) is an actual question from the exam that I did.
I hope that there aren't any more questions in the exam that haven't been checked!!!

Yura,
Welcome to Javaranch, a friendly place for Java greenhorns

We ain't got many rules 'round these parts, but we do got one. Please change your displayed name to comply with the JavaRanch Naming Policy.
Thanks Pardner! Hope to see you 'round the Ranch!

Originally posted by Ravish Kumar:
Manish , article is really superb..
Now I think, when I get newsletter, its better to put 1-2 hr on it.
Thanks a lot.. after a long time got a good article on the simplest class Object and its most common methods.
Keep it up

Thanks Ravish,

A lot of credit goes to Valentin for his detailed feedback and useful corrections.
rgds,
- Manish

sorry.