import java.util.Hashtable;
import java.util.Map;

public class HashcodeTest{
static class DummyObject extends Object { }

public static void reportClash(DummyObject obj1, DummyObject obj2) {
System.out.println(“obj1.hashCode() = ” + obj1.hashCode());
System.out.println(“obj2.hashCode() = ” + obj2.hashCode());
System.out.println(“(obj1 == obj2) = ” + (obj1 == obj2) + ” (!)”);
}

public static void main(String[] args) {
Map map = new Hashtable();
for (int count = 1; true; count++) {
DummyObject obj = new DummyObject();
if (map.containsKey(obj.hashCode())) {
System.out.println(
“Clash found after instantiating ” + count + ” objects.”);
reportClash(map.get(obj.hashCode()), obj);
System.exit(0);
}
map.put(obj.hashCode(), obj);
}
}
}

It repetitively constructs objects, stores them in a Map using their hash code as a key, and detects when a key has already been used and thus two different objects with the same hashCode() result coexists. On my system (Java 6, Ubuntu 10.04) this happens only after 1756 instantiations. The mathematically-inclined might work out the average number of instantiations as a special instance of the birthday paradox, supposing hashCode() aims to be randomly distributed. This confirms, at least for me, that hashCode() is not even in *practical terms* a useful facility to serve as an object identity.

PS: If anyone wants to share some ideas please feel free to get in touch, my email is on my University of York website (http://www-users.cs.york.ac.uk/~zeyda/).

Best wishes,
Frank

PPS: predictable in a sense as independent of the usage pattern of the class. Maybe static is a better word…

Secondly, as the previous couple of posts already state, there is no requirement for hashCode() to yield a unique identifier for an object; a quick look at the method description in the Object class in the Java API confirms this.

http://download.oracle.com/javase/6/docs/api/

But, of course, we *can* obtain a unique identifier for an object: its simply its object reference. The only problem is that we cannot do much with it :D. I.e. we can only check if references are equal or not, but not convert them into numbers as far as I am aware.
This seems only restrictive I believe if we attempt to implement something like a “universal comparator” that works for any kind of object, namely because we cannot do arithmetic comparison with references that would easily induce a total order that the comparator could use to fulfill its contract. Despite I think this problem can be solved.

A hint: one might implement a comparator that first checks if o1.equals(o2) and if so returns null. If not, it stores both objects in a map by assigning consecutive numbers to them when they are first encountered. This induces a total order that the comparator may use to fulfill its contract. The order is not a priori fixed or predictable, but in some case we don’t actually care about that. Also, unlike something like: o1.hashCode() < o2.hashCode() ? 1 : -1 it is consistent with equals. Any more thoughts on this are welcome.

PS: Just my two pence.

Frank

This is so funny, really :-D.