I'm wondering what is the best practice for writing #hashCode() method in java. Good description can be found here. Is it that good?
-
possible duplicate of http://stackoverflow.com/questions/113511/hash-code-implementation – Yishai Apr 29 '10 at 16:21
-
I don't think it really is as current post has a bit wider scope. – Denys S. Apr 29 '10 at 16:24
-
Can you please clarify how your question is different, then? They look the same to me. – Michael Myers Apr 29 '10 at 16:31
-
@mmyers: If we're talking about question, then difference lies at least in their formulation. As for contents, many answers there do answer this one. – Denys S. Apr 29 '10 at 16:43
-
possible duplicate of http://stackoverflow.com/questions/2735037/is-it-incorrect-to-define-an-hashcode-of-an-object-as-the-sum-multiplication-wh – polygenelubricants Apr 30 '10 at 02:03
3 Answers
Here's a quote from Effective Java 2nd Edition, Item 9: "Always override hashCode
when you override equals
":
While the recipe in this item yields reasonably good hash functions, it does not yield state-of-the-art hash functions, nor do Java platform libraries provide such hash functions as of release 1.6. Writing such hash functions is a research topic, best left to mathematicians and computer scientists. [... Nonetheless,] the techniques described in this item should be adequate for most applications.
Josh Bloch's recipe
- Store some constant nonzero value, say 17, in an
int
variable calledresult
- Compute an
int
hashcodec
for each fieldf
that definesequals
:- If the field is a
boolean
, compute(f ? 1 : 0)
- If the field is a
byte, char, short, int
, compute(int) f
- If the field is a
long
, compute(int) (f ^ (f >>> 32))
- If the field is a
float
, computeFloat.floatToIntBits(f)
- If the field is a
double
, computeDouble.doubleToLongBits(f)
, then hash the resultinglong
as in above - If the field is an object reference and this class's
equals
method compares the field by recursively invokingequals
, recursively invokehashCode
on the field. If the value of the field isnull
, return 0 - If the field is an array, treat it as if each element is a separate field. If every element in an array field is significant, you can use one of the
Arrays.hashCode
methods added in release 1.5
- If the field is a
- Combine the hashcode
c
intoresult
as follows:result = 31 * result + c;
Now, of course that recipe is rather complicated, but luckily, you don't have to reimplement it every time, thanks to java.util.Arrays.hashCode(Object[])
.
@Override public int hashCode() {
return Arrays.hashCode(new Object[] {
myInt, //auto-boxed
myDouble, //auto-boxed
myString,
});
}
As of Java 7 there is a convenient varargs variant in java.util.Objects.hash(Object...)
.

- 77
- 1
- 5

- 376,812
- 128
- 561
- 623
A great reference for an implementation of hashCode()
is described in the book Effective Java. After you understand the theory behind generating a good hash function, you may check HashCodeBuilder from Apache commons lang, which implements what's described in the book. From the docs:
This class enables a good hashCode method to be built for any class. It follows the rules laid out in the book Effective Java by Joshua Bloch. Writing a good hashCode method is actually quite difficult. This class aims to simplify the process.

- 51
- 2
- 3
- 10

- 5,488
- 2
- 29
- 36
It's good, as @leonbloy says, to understand it well. Even then, however, one "best" practice is to simply let your IDE write the function for you. It won't be optimal under some circumstances - and in some very rare circumstances it won't even be good - but for most situations, it's easy, repeatable, error-free, and as good (as a hash code) as it needs to be. Sure, read the docs and understand it well - but don't complicate it unnecessarily.

- 39,912
- 17
- 102
- 155
-
Yeah, not an optimal solution when using entities in EJB or alike cases. – Denys S. Apr 29 '10 at 16:34