Use standard JVM library methods to mix hashcodes

[WilliamParker]

The current hashcode implementations appear to follow the pattern here. For convenience I'll copy the method here:

  @Override
  public int hashCode() {

    return 17 * url.hashCode() * version.hashCode();
  }

If the hashcodes collide I don't see how a simple multiplication would help matters, and they would certainly still collide if they were actually equal. In principle in some cases it might help if two hashcodes were in the same bucket but not actually equal depending on the bucketing strategy used, but it seems like collisions would be worsened just as often for any bucketing strategy I can think of.

I think what you actually were going for here is probably a variation on Java's strategy for hashing strings, whereby each member hashcode is effectively multiplied by a different power of a prime number and these results summed. See the implementation for Java 7, noting that previous summands onto h are multiplied by 31 again in successive loops. I can't recall the mathematical explanation behind why sums of this form give a better distribution than alternatives, although I remember having studied it at one point - you could probably find it in an algorithms textbook. In any event though we can probably trust that Java's default for this is reasonable.

The easiest way to get this behavior is likely to use the hashCode method on Objects provided in Java 7+. That ends up using the Arrays hashcode which uses the same algorithm as in String.

I don't see a functional problem here since we seem to still be obeying hashcode and equality contracts - the performance in hash-based data structures probably just won't be quite optimal.