Understanding Hashcodes

[Jart Bo]

Hi,

I'm having a little difficulty understanding hashcodes. Particularly for the SCJP exam, differentiating legal and appropriate.

[Noam Wolf]

Hi Jart,

According to the k&b book (page 606)

* an appropriate hashCode() override sticks to the hashCode() contract (described on page 534 in k&b)

So... while it may be legal to have a hashCode implementation use a transient variable (it will pass compilation) if that object is stored in a hashed collection, then later serialized (which means the transient var will be reset) then deserialized, if you try to look for that object in the collection you stored it in (the hashed one, which will call the hashCode() method on said object) it is quite possible you will not get your object back. So, that would be inappropriate because the contract is not held to (the first 2 points, obviously if you call *equal* on an unserialzed object verses the serialized one you will get false).

Anyway, IMHO I think the fine difference is quite fine and this seems like an uninteresting point to make...

[Ian Edwards]

If you look at the following:

    
public int hashCode() {
return 42;
}

Although it isn't a very good hashCode() method it is legal as it always returns the same value. A non-legal method would be one that returned a different hash code each time you called it.

If you want to use your objects instance variables to calculate a hash code you should ensure that you use the same variables as your equals() method. For example if your equals() method uses its x variable then your hashCode() method should as well. You could be inviting trouble if your hashCode() method was using x and y and the value of y is likely to change over time.

[Jart Bo]

Hi Ian,

In other words, an override that returns a random hash code is illegal, right? Thanks for your reply!

[Paul Clapham]

Originally posted by Jart Bo:
In other words, an override that returns a random hash code is illegal, right?

No, "illegal" is the wrong word there. It's perfectly legal, the compiler will accept it and no exceptions will be thrown at runtime because you chose to do that. It's your other choice: "inappropriate". There aren't any situations where it's a good design to do that, and doing it is going to make your program run in unpredictable wrong ways if you are using hashcodes.

[Jart Bo]

Hi Paul,

Thanks! Now I'm getting your point. So you mean somehow you have to tie the hash code with an instance variable of your class? Please explain how is it to make a good hashCode() override then?
[ February 19, 2008: Message edited by: Jart Bo ]

[Jesper de Jong]

The hashcode of an object is a non-unique identifier for the object. Two objects that are equal must return the same hashcode, and two objects that are different might return the same hashcode.

The implementation of the equals() method in your class determines what it means for two objects to be equal. If you implement an equals() method in your class that looks at certain member variables, then you must also implement a hashCode() method that looks at the same member variables - that's the only way to make sure that you don't violate the rule that two objects that are equal must have the same hashcode.

More info: Equals and Hash Code
[ February 20, 2008: Message edited by: Jesper Young ]