What is a .hashcode() anyway?
I remember talk of hash codes around the office a while ago, but since there is a lot of talk about things I don’t understand, I wasn’t sure how advanced a topic it was or if I should be concerned about it yet.
But one of my stories this week is to implement a hash map and unsurprisingly hash codes play an important role in how hash maps work so I have started to look into them.
Calling .hashCode() on an object returns a 32-bit sized integer that has been assigned to that instance of the class when it was first created. Every object created in Java has a hashcode associated with it.
All java classes inherit a basic hash scheme from java.lang.Object but this can be overridden because a custom one may handle the data better.
Those that are overridden should behave with the same contract as Java’s equals() method:
- If two objects are equal, their hash code should be the same.
- If two objects are not the same, they do not need to have the different hash codes (they can be assigned the same hash code).
This is important because if you call something by the same name that is pretty well known and widely used, most programmers expect it to behave in a certain way and so you should stick to this expected behaviour when you override how a hashcode is generated.
In an ideal world, for sake of efficiency, all unequal objects should have different hash codes (this is called the perfect hash), but this calculation can be difficult to come up with and mostly relatively efficient ones will do for smaller data structures.
This is how the hash codes for strings are generated:
s[i] = i(th) character of the string
n = length of the string