hashcode() and equals()

[Rajesh Chandra]

Hi ,
I stumbled on this question-

Given that the objects denoted by the parameters override the equals() and the hashCode() methods appropriately, which return values are possible from the following method?

String func(Object x, Object y) {
return (x == y) + " " + x.equals(y) + " " + (x.hashCode() == y.hashCode());
}

Select the two correct answers.

a "false false true"

b "false true false"

c "false true true"

d "true false false"

e "true false true"
The answer is a and c .How can it be?
In option a if x.equals(y) is false then how can be (x.hashCode() == y.hashCode() true?
regs Rajesh

[Prathiba Kalirengan]

"It is generally necessary to override the hashCode method whenever equals method is overridden, so as to maintain the general contract for the hashCode method, which states that equal objects must have equal hash codes "

If the equals () method and hashcode methods are overridden according to the ideal definition, the correct answers will be

1.true true true
2.false false false
3.false true true--(c)

But a." false false true " is possible though it is not correct.But other options is impossible.

[ December 12, 2005: Message edited by: Prathiba Kalirengan ]
[ December 12, 2005: Message edited by: Prathiba Kalirengan ]

[Seb Mathe]

" false false true " is possible and Correct !

Part of the contract of hashcode() :

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.


It is sometimes impossible to produce different hashcodes for two different objects (regarding equals method).
Look at the Long object : Long L1 and Long L2 are equals if L1.longValue() == L2.longValue();
But there are 2^64 different possible values for a long, and hashcode() should produce an int...

[Prathiba Kalirengan]

In case of "false false true" ,the implementation of hashCode method is inappropriate.In the question they mention that the equals and hashcode methods are overridden appropriately.

[Seb Mathe]

I disagree...

Object x = new Long(1L);
Object y = new Long(4294967296L);
System.out.println(func(x,y));

will print false, false, true, and I dont't think that Sun's implementation of hashcode() for the Long class is inappropriate...

[Prathiba Kalirengan]

I agree with u.I think it holds true for strings too

[Rajesh Chandra]

Thank you Sebe but as Prathiba pointed out it may work with strings too.Well I tried and it doesnt.In what all cases can we expect such situations? How to be sure to be precise in scjp exam??
regs Rajesh

[Jeff Albertson]

As Seb pointed out, there is a pigeon hole principle at work here: since
hasCode returns an int, there are 2^32 possible hash codes and many classes
have more than that many possible distinct (non-equal) values.
What I walk away with is that equal hasCode values don't imply equal (or ==)
objects, but a well-written hasCode should make this likely. For
example, an implementation of hashCode for String that only used the first
few letters wouldn't be a very good one!

[Ernest Friedman-Hill]

Originally posted by Rajesh Chandra:
Thank you Sebe but as Prathiba pointed out it may work with strings too.Well I tried and it doesnt.In what all cases can we expect such situations? How to be sure to be precise in scjp exam??
regs Rajesh

You tried all possible pairs of unequal Strings and didn't find any pairs that had the same hashCode? Wow, that must have taken a very long time!

Seriously, such pairs do exist. Finding them may be tricky, but that doesn't mean they're not there. Such pairs exist whenever there can be more than 2^32 distinct objects of a class, so they're not rare at all. They're the rule rather than the exception.

How to be precise for the SCJP? Well, here at JavaRanch we believe the best thing to do is to actually understand what's going on. If you truly understand the discussion here, then the SCJP presents no problems. If you're just looking for a quick study, well, then just memorize "a and c", and hope for the best!

[Jeff Albertson]

public class Test {
    public static void main(String[] args) {
        System.out.println("\"ab\".hashCode()=" + "ab".hashCode());
        System.out.println("\"bC\".hashCode()=" + "bC".hashCode());
    }
}

How did I find "bC"? I read the API for String.hasCode:

Returns a hash code for this string. The hash code for a String object is computed as

s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]

using int arithmetic, where s[i] is the ith character of the string, n is
the length of the string, and ^ indicates exponentiation. (The hash value
of the empty string is zero.)

[Junilu Lacar]

Originally posted by Rajesh Chandra:
In what all cases can we expect such situations? How to be sure to be precise in scjp exam?

Understand the full contract for 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.

Look at the third bullet point.
[ December 12, 2005: Message edited by: Junilu Lacar ]