java - Sun が String.hashCode() 実装を指定したのはなぜですか?

Question

String.hashCode()技術的に言えば、仕様 (Javadoc) によって保証されているため、の現在の実装に依存することが安全かどうかについては、進行中の議論があるようです。

1. SunString.hashCode()が仕様で の実装を指定したのはなぜですか?
2. 開発者が hashCode() の特定の実装に依存する必要があるのはなぜですか?
3. String.hashCode()太陽が将来変わると空が落ちることを恐れているのはなぜですか? （これはおそらく＃2で説明されています）

Answer 1

hashCode() の特定の実装に依存する理由は、それがデータベース、ファイル、またはその他の記憶媒体に永続化される場合です。ハッシュアルゴリズムが変更されたときにデータが読み戻された場合、Bad Things (tm) が発生します。予期しないハッシュの衝突が発生する可能性があり、さらに懸念されるのは、永続化されているデータと「現在」の間でハッシュが変更されたため、ハッシュによって何かを見つけることができないことです。

実際、それはポイント＃3もほとんど説明しています=）

ポイント＃1の理由は、「相互運用性を可能にするため」である可能性があります。hashCode 実装がロックダウンされている場合、Java の異なる実装間でデータを非常に安全に共有できます。つまり、特定のオブジェクトのハッシュは、実装に関係なく常に同じになります。

Answer 2

元のクラスから実装が変更されました。String思い出すと、「長い」文字列のハッシュでは、16 番目 (?) ごとの文字のみが使用されていました。

Java の後続バージョン間、または異なるベンダーのランタイム間でのシリアライゼーションの相互運用性を促進するために指定されている場合があります。プログラマーは特定の実装に直接依存するべきではありませんが、それを変更すると、多くのシリアル化されたコレクションがhashCode()壊れる可能性があることに同意します。