Comments on: Java gotcha: anArray.hashCode isn’t deep http://www.databasesandlife.com/java-gotcha-anarrayhashcode-isnt-deep/ Adrian Smith's blog Mon, 06 Feb 2012 05:20:25 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: John http://www.databasesandlife.com/java-gotcha-anarrayhashcode-isnt-deep/comment-page-1/#comment-5411 John Thu, 09 Jul 2009 17:11:24 +0000 http://www.databasesandlife.com/java-gotcha-anarrayhashcode-isnt-deep/#comment-5411 Warning, do not use the code recommended above: <code> Map<Integer, byte[]> map = new HashMap<Integer, byte[]>(); map.put(Arrays.hashCode(anArray), anArray); Collection<byte[]> uniqueByteArrays = map.values(); </code> It is true that two identical arrays will hash to the same integer value, but the inverse is <em>not</em> true. It is possible that two different arrays could hash to the same integer value. There are only so many integers, while the number of different integer arrays is almost unlimited. Warning, do not use the code recommended above:


Map<Integer, byte[]> map = new HashMap<Integer, byte[]>();
map.put(Arrays.hashCode(anArray), anArray);
Collection<byte[]> uniqueByteArrays = map.values();

It is true that two identical arrays will hash to the same integer value, but the inverse is not true. It is possible that two different arrays could hash to the same integer value. There are only so many integers, while the number of different integer arrays is almost unlimited.

]]> By: Peter Lawrey http://www.databasesandlife.com/java-gotcha-anarrayhashcode-isnt-deep/comment-page-1/#comment-429 Peter Lawrey Mon, 12 May 2008 11:24:56 +0000 http://www.databasesandlife.com/java-gotcha-anarrayhashcode-isnt-deep/#comment-429 Unfortunately, arrays inherit their implementation of hashCode(), equals() and toString() fro Object. There is no Array class type that all array inherit from only an Array & Arrays helper classes. This means the hashCode for an array is based on it internal object number, equals is only true for the same object and toString() prints the internal class name and the internal id... Not very useful IMHO. Unfortunately, arrays inherit their implementation of hashCode(), equals() and toString() fro Object. There is no Array class type that all array inherit from only an Array & Arrays helper classes.
This means the hashCode for an array is based on it internal object number, equals is only true for the same object and toString() prints the internal class name and the internal id… Not very useful IMHO.

]]> By: Vesa Karvonen http://www.databasesandlife.com/java-gotcha-anarrayhashcode-isnt-deep/comment-page-1/#comment-325 Vesa Karvonen Thu, 27 Mar 2008 14:40:28 +0000 http://www.databasesandlife.com/java-gotcha-anarrayhashcode-isnt-deep/#comment-325 The (default) hash of mutable objects should only depend on the identity of the object. If this isn't the case, then mutating the object changes the hash. This, in turn, breaks the assumptions of data structures (read: hash tables) based on hashing. Let's assume that the hash of an array would depend on the elements stored in the array. Consider a program that first inserts an array into a hash table and then mutates the array. After the mutation, the hash of the array has changed. Trying to lookup the array will now fail. Of course, one fundamental problem with Java is that it doesn't provide a comprehensive set of immutable data types. This leads to many kinds of problems. One well known problem is the need to make copies of data structures before returning them to avoid clients to break class invariants via mutation. Contrast with a sane imperative language like Standard ML that provides comprehensive support for both mutable (ref cells and arrays) and immutable data types (vectors, tuples, records, variant types, numeric types, ...). In Standard ML one can entirely avoid using mutable data types in interfaces except when the data structures are supposed to be mutated by the clients. Consequently, there is basically never need to make copies of data structures just to be safe. The (default) hash of mutable objects should only depend on the identity of the object. If this isn’t the case, then mutating the object changes the hash. This, in turn, breaks the assumptions of data structures (read: hash tables) based on hashing. Let’s assume that the hash of an array would depend on the elements stored in the array. Consider a program that first inserts an array into a hash table and then mutates the array. After the mutation, the hash of the array has changed. Trying to lookup the array will now fail.

Of course, one fundamental problem with Java is that it doesn’t provide a comprehensive set of immutable data types. This leads to many kinds of problems. One well known problem is the need to make copies of data structures before returning them to avoid clients to break class invariants via mutation. Contrast with a sane imperative language like Standard ML that provides comprehensive support for both mutable (ref cells and arrays) and immutable data types (vectors, tuples, records, variant types, numeric types, …). In Standard ML one can entirely avoid using mutable data types in interfaces except when the data structures are supposed to be mutated by the clients. Consequently, there is basically never need to make copies of data structures just to be safe.

]]>