Making a hash of hashCode

Dear Experts,

I have some simple data beans that need to override hashCode.  One of you Experts gave me a simple hasCode example a while back, which I implemented like this:

      public int hashCode()
            int hash = 17;
            hash = hash * 37 + bankID;
            hash = hash * 37 + applicationCode;
            hash = hash * 37 + (int) accountNbr; // this is a long
            return hash;

My problem is, at least on this example, accountNbr is a long, not an int.  (It a ten-byte numeric.)  So I'm obviously losing some precision here.  

My question is: Is that a little bit bad, or just plain wrong?  (If it just means less-than-optimal sorting, for instance, that's OK for my purposes.)  

And if it's just plain wrong, what do I do?  hashCode needs to return an int, right?

Thanks again...
Who is Participating?
fffej78Connect With a Mentor Commented:
In a hash table, collisions are bad and adversely affect look-up time.  In general, you are right, there is no such thing as a perfect hash code for any sufficiently large data set.  If you know all the possibilities you can generate a perfect hash function, see for example

What you don't want is a hash function that collides very often.  As long as you follow the standard guidelines (see ), you should be fine.  Guidelines reproduced below:  

    * if a class overrides equals, it must override hashCode
    * if two objects are equal, then their hashCode values must be equal as well
    * if a field is not used in equals, then it must not be used in hashCode
    * if it is accessed often, hashCode is a candidate for caching

Java doesn't have a sorted hash map, though it does have a sorted map.  See

I'm not sure why you'd want to sort the bean hashcode though.  Can you give some examples of how you intend to use this hashcode?  Or what you intend doing with the bean in the way of collections etc?
BrianMc1958Author Commented:
BTW: bankID and applicationCode are both ints.
If you are using Java5, you could try using a prebuilt hashcode function instead.

import java.util.Arrays;

public int hashCode()
  return Arrays.hashCode( new long[] {bankID, applicationCode, accountNbr } );

I don't think your method is wrong.  Hashcode generally isn't used for sorting, it is for hash maps and the like though.
BrianMc1958Author Commented:
Actually, the whole hashCode thing is still something of a mystery to me.  When I mentioned sorting, it was with hash maps in mind.  My vague understanding is that the hashCode result (as opposed the the "equals" result) does not need to be unique for all objects.   It's one of the few times in our profession where close is good enough.  Is that correct?
BrianMc1958Author Commented:
Actually, you've answered my question.  I shouldn't have mentioned sorting in the first place.  I just think of hashing as being like sorting, which is off the point here.  In my case, a collision will occur very rarely, so it looks like I'm OK.

Thanks a lot!
All Courses

From novice to tech pro — start learning today.