title: What is a sensible prime for hashcode calculation?
body: <p>Eclipse 3.5 has a very nice feature to generate Java hashCode() functions. It would generate for example (slightly shortened:)</p>
  
  <pre><code>class HashTest {
      int i;
      int j;        
      public int hashCode() {
          final int prime = 31;
          int result = prime + i;
          result = prime * result + j;
          return result;
      }
  }
  </code></pre>
  
  <p>(If you have more attributes in the class, <code>result = prime * result + attribute.hashCode();</code> is repeated for each additional attribute. For ints .hashCode() can be omitted.)</p>
  
  <p>This seems fine but for the choice 31 for the prime. It is probably taken from the <a href="https://stackoverflow.com/questions/299304/why-does-javas-hashcode-in-string-use-31-as-a-multiplier">hashCode implementation of Java String</a>, which was used for performance reasons that are long gone after the introduction of hardware multipliers. Here you have many hashcode collisions for small values of i and j: for example (0,0) and (-1,31) have the same value. I think that is a Bad Thing(TM), since small values occur often. For String.hashCode you'll also find many short strings with the same hashcode, for instance "Ca" and "DB". If you take a large prime, this problem disappears if you choose the prime right.</p>
  
  <p>So my question: what is a good prime to choose? What criteria do you apply to find it? </p>
  
  <p>This is meant as a general question - so I do not want to give a range for i and j. But I suppose in most applications relatively small values occur more often than large values. (If you have large values the choice of the prime is probably unimportant.) It might not make much of a difference, but a better choice is an easy and obvious way to improve this - so why not do it? Commons lang <a href="http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/builder/HashCodeBuilder.html" rel="noreferrer">HashCodeBuilder</a> also suggests curiously small values.</p>
  
  <p>(<strong>Clarification</strong>: this is <em>not</em> a duplicate of <a href="https://stackoverflow.com/questions/299304/why-does-javas-hashcode-in-string-use-31-as-a-multiplier">Why does Java's hashCode() in String use 31 as a multiplier?</a> since my question is not concerned with the history of the 31 in the JDK, but on what would be a better value in new code using the same basic template. None of the answers there try to answer that.)</p>