I know that hashcode is a unique number that identifies objects, but it can't be like a memory address cause 2 different objects can have the same hashcode, right? I'm confused about what this hashcode is exactly. How is it calculated? And what is it used for?
Michael J Bruesch<br /><i>I code, therefore I am.</i>
JavaBeginnersFaq "Yesterday is history, tomorrow is a mystery, and today is a gift; that's why they call it the present." Eleanor Roosevelt
Joined: Sep 23, 2001
Yeah, I looked through the API and also read about hashcodes in many different resources, but still never fully understood how they were calculated. I know they're used for the equals() method, but how exactly are they calculated? And are they small ints, like 1 or 2, or big like 214563 or something? And do we ever need to know the exact value of the hashcode? Or can we just rely that they are there and if 2 objects are "equals" then their hashcodes will be the same? And I'm not that familiar with hashtables, never used them. I'll read up more on those, maybe that will clear up some of the cobwebs for me. Thanks Marilyn!
I learned about hashcodes by reading Data Structures and Algorithms in Java by Mitchell Waite. Although I'm sure there are other resources about them, I haven't persued it further. [This message has been edited by Marilyn deQueiroz (edited November 04, 2001).]
Anyone can write a hashcode algorithm. As a matter of fact, if you are writing a class, and you decide to override the equals() method of Object, then it is STRONGLY recommended that you create an appropriate hashcode() to go with it. This is so that you preserve the contract of .equals that says that if two things are equal - they will return the same hashcode. The .equals of Object just looks to see if they both point to the SAME instance. Remember that the reason that you want one of these things to begin with is to create some sort of ordering mechanism to increase performance when dealing with things like hashTables and such. The only rules are: 1. It must return an int value. 2. If two instances of the class are .equal() then they MUST return the same hashcode. Two unequal instances are allowed to return the same hashcode.
You COULD have a hashcode method that always returns the same integer. It would be LEGAL (although not too intelligent). So the next consideration is - how complicated do you want this hashcode algorithm to be. If you make it too simpilistic (like above) then too many instances will result in the same hashcode and you wont get any sorting or searching benefit out of it. On the other hand if you make it too complicated the benefit gained by having unique hashcodes gets eaten up by the resources required to calculate the darn thing to begin with. Therefore you need to find some middle ground. Somewhere where MOST of the instances are going to have unique hashcodes, but if the occasional case happens and they are not unique it will not slow down performance much.
"JavaRanch, where the deer and the Certified play" - David O'Meara
Although this method is implemented in class Object, it is recommended that you override this method and provide your own implementation for classes you write. Just as it is a good idea to provide your own overriding 'equals()' and 'toString()' methods. How you implement hashCode() is completely up to you as long as it satisfies the hashCode() contract - you can see this in the java docs API for the Object class. So for example if you are writing a Time class that holds hours (HH), minutes (MM) and seconds (SS) then your implementation of hashCode() might return the integer represented by HHMMSS or you might decide to return the integer representing the number of seconds past midnight that the Time object represents. It's your choice. Or in a 'Person' object you might concatenate the Surname with Forename and use String's hashCode() method to get the integer to return. So as to the size of the integer - it can be whatever you want it to be. One thing to bear in mind though is that the way you compute hashcodes could have an influence on the performance of hashtables, hashmaps etc. as it would increase look up times if many unequal objects had the same hashcode.