Question

While perusing the source for AbstractMap in Java I ran across this:

440      /** 
441       * Returns the hash code value for this map.  The hash code of a map is 
442       * defined to be the sum of the hash codes of each entry in the map's 
443       * <tt>entrySet()</tt> view.  This ensures that <tt>m1.equals(m2)</tt> 
444       * implies that <tt>m1.hashCode()==m2.hashCode()</tt> for any two maps 
445       * <tt>m1</tt> and <tt>m2</tt>, as required by the general contract of 
446       * {@link Object#hashCode}. 
447       * 
448       * <p>This implementation iterates over <tt>entrySet()</tt>, calling 
449       * {@link Map.Entry#hashCode hashCode()} on each element (entry) in the 
450       * set, and adding up the results. 
451       * 
452       * @return the hash code value for this map 
....  
456       */ 
457      public int hashCode() { 
458      int h = 0; 
459      Iterator<Entry<K,V>> i = entrySet().iterator(); 
460      while (i.hasNext()) 
461          h += i.next().hashCode(); 
462      return h; 
463      }

This is interesting because of what it – seemingly accidentally – precludes in the way of hashcodes.

If this method is to work as written, it precludes the use of hashcodes which, when summed together, exceed Integer.MAXINT. If you’re writing your own hashcode, you may want to know about this.

I can think of at least one useful definition of hashcode that could run afoul of this and moreover it seems to be sensitive to the amount of data in the hashmap. Specifically, the more data in the map, the larger the entrySet, the larger the running total of hashcodes.

This really seems like an undocumented side-effect and also just a plain old Bad Idea. The intent seems to be to leverage the commutative law of addition (a+b == b+a) to produce the required equality of maps with the same entries, but wow, what a bad implementation.

This requires anyone overriding hashcode – which is anyone who doesn’t want merely object-instance brand equality ( == i.e. most people), to know things which they can’t or aren’t likely to know. The first one is the cumulative sum of their hashcodes (who ever thinks of this??) and the other is the maximum number of items that will ever be entered into a map and how that could effect the cumulative sum.

This is just whacked-a-doodled. Anyone have any insight? hashcode() is derived from the class Object if it matters.

Answer 1

int will wrap around / overflow so going above Integer.MAX_VALUE will not throw an exception or cause problems here.

The main concept here is that hashCode should yield identical (integer) values for objects that are considered identical (in a particular run of your program). This code fulfills that requirement.

Note that hashcode collisions can and will happen occasionaly, that’s you always need to provide a meaningful equals override when overriding hashcode.