Es scheint eine anhaltende Debatte darüber zu geben, ob es sicher ist, sich auf die derzeitige Umsetzung von String.hashCode() zu verlassen, da dies technisch gesehen durch die Spezifikation (Javadoc) garantiert wird.
String.hashCode() in der Spezifikation spezifiziert? String.hashCode() in der Zukunft geändert wird? (Dies wird wahrscheinlich durch # 2 erklärt) Ein Grund dafür, sich auf die spezifische Implementierung von hashCode () zu verlassen, wäre, wenn es jemals in einer Datenbank, Datei oder irgendeinem anderen Speichermedium gespeichert wird. Schlechte Dinge (tm) würden passieren, wenn die Daten zurückgelesen würden, wenn sich der Hash-Algorithmus geändert hätte. Sie könnten auf unerwartete Hash-Kollisionen stoßen, und noch beunruhigender ist die Unfähigkeit, etwas durch seinen Hash zu finden, da sich der Hash zwischen den Daten geändert hat, die persistent und "jetzt" sind.
Tatsächlich erklärt das ziemlich genau Punkt # 3 =)
Der Grund für Punkt # 1 könnte "Interoperabilität" sein. Wenn die hashCode-Implementierung gesperrt ist, können Daten zwischen verschiedenen Implementierungen von Java ziemlich sicher geteilt werden. D. h., der Hash eines gegebenen Objekts wird unabhängig von der Implementierung immer gleich sein.
Die Implementierung hat seit der ursprünglichen String -Klasse geändert. Wenn ich mich erinnere, war es früher so, dass nur jedes 16. (?) Zeichen im Hash für "lange" Zeichenfolgen verwendet wurde.
Es wurde möglicherweise angegeben, die Serialisierungsinteroperabilität zwischen nachfolgenden Versionen von Java oder sogar zwischen den Laufzeiten verschiedener Anbieter zu fördern. Ich stimme zu, ein Programmierer sollte sich nicht direkt auf eine bestimmte Implementierung von hashCode() verlassen, aber das Ändern könnte möglicherweise ein Los von serialisierten Sammlungen zerstören.
Tags und Links string java hashcode backwards-compatibility