Title: RE: [jdjlist] Proper ( or improper ) implementation of the hashCode method

<REF>
  There is a great discussion of this in my fav. book: Effective Java by J. Bloch.
</REF>

Just like the doc says, it is basically the number "index" under which the object will be hashed in the Hashtable etc.  If you're going to store a bunch of these in a collection, you're better off making sure that your hashCodes are different for unequal instances of this object, so the hashing function does not have to provide an extra "differentiation number", which will decrease it's "find" efficiency, and make it more dependent on (n).

So you must take into account all the internals of your object.  With custom collections, or internalized collections, I remember reading that a good way to do this, is to multiply the individual hashing code of each object contained in the collection, by its index in the collection.


For ex: let's say you got a vector of {a, b, c} in the custom object abc for which you need a hashCode.

you would do something like:
int hashCode = 0;

for(int i = 0; i < vector.size(); i++) {
        hashCode += ((vector.elementAt(i)).hashCode() * i);
}


this way, you will avoid the same hashCode being produced by:
object cba contains Vector {c, b, a}

You can also do this for List, Set, etc. by getting an Enumeration and iterating through the ellements. 

Multiplying i by a good-sized prime number is also a good tip I heard.

Any thoughts?

Greg



-----Original Message-----
From: Java exams [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, June 25, 2002 9:05 AM
To: JDJList
Subject: [jdjlist] Proper ( or improper ) implementation of the hashCode
method



What distinguishes a proper ( versus an improper )
implementation of the hashCode() method?

What do I need to "watch out" for when
implementing a hashCode() method?  Any
"learned the hard way" lessons people have to
share on proper versus improper implementations of
hashCode?  Anything unique when dealing with
Collection classes?



Here is text from java.lang.Object:

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 much as is reasonably practical, the hashCode
method defined by class Object does return distinct
integers for distinct objects. (This is typically
implemented by converting the internal address of the
object into an integer, but this implementation
technique is not required by the JavaTM programming
language.)


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

To change your membership options, refer to:
http://www.sys-con.com/java/list.cfm

To change your membership options, refer to:
http://www.sys-con.com/java/list.cfm

Reply via email to