What would happen if
Integer
did not override equals()
and hashCode()
? Nothing, if we never used an Integer
as a key in a HashMap
or other hash-based collection. However, if we were to use such an Integer
object for a key in a HashMap
, we would not be able to reliably retrieve the associated value, unless we used the exact sameInteger
instance in the get()
call as we did in the put()
call. This would require ensuring that we only use a single instance of the Integer
object corresponding to a particular integer value throughout our program. Needless to say, this approach would be inconvenient and error prone.The interface contract for
Object
requires that if two objects are equal according to equals()
, then they must have the same hashCode()
value. Why does our root object class need hashCode()
, when its discriminating ability is entirely subsumed by that of equals()
? The hashCode()
method exists purely for efficiency. The Java platform architects anticipated the importance of hash-based collection classes -- such as Hashtable
, HashMap
, and HashSet
-- in typical Java applications, and comparing against many objects with equals()
can be computationally expensive. Having every Java object support hashCode()
allows for efficient storage and retrieval using hash-based collections.Find good article here and there
http://www.syntax-example.com/Code/show-simple-implementation-hashing-981.aspx
http://www.syntax-example.com/Code/show-simple-implementation-hashing-981.aspx
No comments:
Post a Comment