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 intvariable calledresult
- Compute an inthashcodecfor each fieldfthat 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 resultinglongas in above
- If the field is an object reference and this class's equalsmethod compares the field by recursively invokingequals, recursively invokehashCodeon 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.hashCodemethods added in release 1.5
 
- If the field is a 
- Combine the hashcode cintoresultas 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
