3 ms·
Please see javadoc for String.hashCode: http://docs.oracle.com/javase/6/docs/api/java/lang/String.html#hashCode() http://docs.oracle.com/javase/6/docs/api/java
by jdsullivan 14y ago
Please see javadoc for String.hashCode:
http://docs.oracle.com/javase/6/docs/api/java/lang/String.html#hashCode() http://docs.oracle.com/javase/6/docs/api/java/lang/String.ht...
It's true that relying on hashCode to remain stable across arbitrary objects is brittle, but this is not the case for String.
- scott_s 14y agoIt's also true that the author made the same point.
- jdsullivan 14y agoNot quite: "On strings, numbers and collection classes, hashCode() always returns a consistent value, apparently even across different JVM vendors. It’s like that despite the documentation for hashCode() explicitly not guaranteeing consistency across different processes" String.hashCode explicitly guarantees consistency across processes by specifying how the hash code is computed, this is something that can be safely relied upon. (Same for Integer, Long, Float and Double)