CODEWITHSUNDEEP
javaobject
James Raitsev
James Raitsev

Reputation: 96471

"Deep equality" test and hashCode()

Suppose a class MyClass has 3 variables, a,b and c. This class also overrides hashCode() that calculates return value using Joshua Bloch's approach.

Assuming the above, would it be correct to assume that MyClass() and new MyClass() are deeply equal if their hashcodes match?

For the purposes of the example, assume that both objects are initialized with the same parameters

Upvotes: 3

Views: 905

Answers (3)

Jon Bright
Jon Bright

Reputation: 13738

Other answers are correct, but here's an alternative way to look at it: hashCode returns an int. If you have an object that has a String as its only member and that string contains more than 4 bytes' worth of characters, then you already have more information in that String than can be expressed using an int. Once you realise this, it becomes clear that there's no way the value returned by hashCode can be a complete representation of the object.

Since the value returned by hashCode can't completely represent the object, it clearly can't be used to determine whether the objects are semantically equal.

One thing you can do if the hashCodes of two objects are equal: you can assume there's a fairly reasonably chance that they're the same object. Thus, e.g. HashMap first locates a hash bucket according to the hash code, but then looks through each object it finds there (using equals) to find an object semantically equivalent to the one you actually wanted.

Upvotes: 0

Arnout Engelen
Arnout Engelen

Reputation: 6907

Certainly not.

hashCode is required to yield the same value for equivalent objects, but different objects may yield the same value. So, the following is a correct (but inefficient) hashCode implementation:

public int hashCode()
{
    return 42;
}

Even when you know a specific hashing method is used, it is a bad idea to assume hashCode is perfect: later, some refactoring/subclass might replace the hashCode implementation with something else. If you want this, create a perfectHashCode method that does always return a perfect hashcode, and use that for implementing hashCode

To answer your initial question: no, even Bloch's approach afaics does not yield a perfect hashCode, because (because of wrapping over MAXINT) 2 different paths might eventually collide into the same hash code.

This is easy to imagine: say your object holds 2 integers. The hash code is only 1 integer. So it can never yield a different value for each combination of 2 integers.

Upvotes: 5

ColinD
ColinD

Reputation: 110084

You can never assume two objects are equal if their hash codes match. The hash codes being equal only means that the objects may be equal and that equals must be called to determine for sure. The hash codes being different means that the objects are definitely not equal (provided hashCode() is correctly consistent equals).

Upvotes: 0

Related Questions