There seems to be an ongoing debate about whether it is safe to rely on the current implementation of String.hashCode() because, technically speaking, it is guaranteed by the specification (Javadoc).
String.hashCode()'s implementation in the specification?String.hashCode() is changed in the future? (This is probably be explained by #2)A reason for relying on the specific implementation of hashCode() would be if it is ever persisted out into a database, file or any other storage medium. Bad Things(tm) would happen if the data was read back in when the hashing algorithm had changed. You could encounter unexpected hash collisions, and more worryingly, the inability to find something by its hash because the hash had changed between the data being persisted and "now".
In fact, that pretty much explains point #3 too =)
The reason for point #1 could be "to allow interoperability". If the hashCode implementation is locked down then data can be shared between different implementations of Java quite safely. i.e, the hash of a given object will always be the same irrespective of implementation.
The implementation has changed since the original String class. If I recall, it used to be that only every 16th (?) character was used in the hash for "long" strings.
It may have been specified to promote serialization interoperability between subsequent versions of Java, or even between the runtimes of different vendors. I agree, a programmer should not rely on a particular implementation of hashCode() directly, but changing it could potentially break a lot of serialized collections.