6

I'm thinking about a hash function for arbitrary Java-objects for exercise means. The naive way would be to call the hashCode()-function for each attribute, add these hashes and then take the sum modulo the maximal hash value, or something like that. However, that would mean, that the hash value would change whenever on of the attributes is changed, so this method cannot be used if you want to store objects in a hash table. The hash code of an object should represent its identity. But how can I express this abstract identity as an integer value? Maybe by using the object address (supposing, Java doesn't move objects in the memory during runtime), but is there a way in Java to get an objects address?

How would you implement such a hash function?

Thanks in advance.

j0ker
  • 4,069
  • 4
  • 43
  • 65
  • 1
    for details about GC moving objects and hashcodes see http://stackoverflow.com/questions/7207302/if-javas-garbage-collector-moves-objects-what-is-object-hashcode-and-system-ide – Nathan Hughes Sep 14 '11 at 21:23

3 Answers3

4

I think Effective Java's chapter about methods common to all objects is a great resource here.

Johannes Weiss
  • 52,533
  • 16
  • 102
  • 136
3

java.lang.System has a method identityHashCode(Object) which returns a value that doesn't change for the life of an object. It may be related (in some mystical, implementation-dependent way) to the object's machine address. Anyway, this is why that method is there.

Ernest Friedman-Hill
  • 80,601
  • 10
  • 150
  • 186
  • Wouldn't this fail the equals test for objects such as Integer as was asked? – John B Sep 14 '11 at 21:12
  • I think you mean: System.identityHashCode(object). The identityHashCode method doesn't belong to java.lang.Object. – Cory Kendall Sep 14 '11 at 21:14
  • Yes indeed, it would. But if you want an immutable hash for mutable objects, then it will always fail this test unless it always returns the same value for any object. The poster wants an identity-based hash, and this is it. You can't have your cake and eat it too. – Ernest Friedman-Hill Sep 14 '11 at 21:14
  • That seems a bit like cheating, but at least it works. By the way, would it work to just save the timestamp when the object is created as hash value? – j0ker Sep 14 '11 at 21:36
  • You can create many objects in a millisecond, so there's a pretty high risk that you'd end up with non-unique values that way. – Ernest Friedman-Hill Sep 14 '11 at 22:53
2

That would not be an appropriate hash function. Remember that hashCode should return the same value if two objects are equal (according the to the equal method). Therefore, using the memory address of the object would not satisfy this criteria.

Check out the hashCode contract. http://download.oracle.com/javase/6/docs/api/java/lang/Object.html#hashCode()

John B
  • 32,493
  • 6
  • 77
  • 98
  • But in the last line it says for java.lang.Objects they indeed usually use the object's addresses. So I guess, if we suppose that the generic object is only equal to another if it has the same identity, using the memory address would be appropriate. – j0ker Sep 14 '11 at 21:30
  • 1
    That is correct. So long as equals is based on identity and no two distinct instance of a class may be equal, then using the Object's default mechanism of the address is valid. – John B Sep 14 '11 at 22:52