Infrequent Update

Friday, August 31, 2012

Better approach to make hashing in Java more flexible

Today I received the newsletter from www.javaperformancetuning.com which covers a recent change in the implementation of hash tables in Java. They claim "The generic way to do this" (meaning, providing a custom hash function other than what Object.hashCode() and overridden versions provide) would be to define an interface Hashable with a new method hash() defined. However, there is an easy approach available which is much more flexible:

/**
 * This interface abstracts algorithms used
 * for hash structures.  Implementations
 * must observe the proper contract (i.e.
 * if {@link #equals(T,T)} returns
 * <code>true</code> {@link #hashCode(T)}
 * must return identical values for both
 * instances).
 */
public interface HashAlgorithms<T> {

  /**
   * Calculate the hash code for the given instance.
   *
   * @param object any object, may be <code>null</code>
   * @return the hash code.
   * @see Object#hashCode()
   * @see Object#equals()
   */
  int hashCode(T object);

  /**
   * Compare two instances for equality.
   *
   * @param a any object, including <code>null</code>.
   * @param b any object, including <code>null</code>.
   * @return <code>true</code> if both instances are considered equal.
   * @see Object#hashCode()
   * @see Object#equals()
   */
  boolean equals(T a, T b);
}

By having this and of course changing java.util.HashMap and the like to accept an instance of this interface at construction time it is immediately obvious that we would not need class IdentityHashMap.

Why did nobody think of this?