Perché Sun ha specificato String.hashCode) realizzazione (?

Question

Sembra che ci sia un dibattito in corso sul fatto che è sicuro di fare affidamento su l'attuale implementazione di String.hashCode() perché, tecnicamente parlando, è garantito dalla specifica (Javadoc).

1. implementazione Perché Sun ha specificato di String.hashCode() nella specifica?
2. Perché dovrebbero sviluppatori mai bisogno di fare affidamento su una specifica implementazione di hashCode ()?
3. Perché il Sole così paura che il cielo cadrà se String.hashCode() viene modificato in futuro? (Questo è probabilmente essere spiegato con # 2)

Answer 1

Un motivo per affidamento sulla specifica implementazione di hashCode () sarebbe se è sempre persistito fuori in un database, file o qualsiasi altro supporto di memorizzazione. Bad Things (tm) sarebbe successo se i dati sono stati riletti in cui l'algoritmo di hashing era cambiato. Si potrebbe incontrare collisioni hash inaspettati, e più preoccupante, l'incapacità di trovare qualcosa dal suo hash perché l'hash era cambiato tra i dati che vengono persistevano e "ora".

In realtà, che spiega più o meno il punto # 3 troppo =)

Il motivo per il punto # 1 potrebbe essere "per consentire l'interoperabilità". Se l'attuazione hashCode è bloccata quindi i dati possono essere condivisi tra le diverse implementazioni di Java in tutta sicurezza. cioè, l'hash di un oggetto sarà sempre lo stesso indipendentemente attuazione.

Answer 2

L'implementazione ha cambiato da quando la classe String originale. Se non ricordo male, è usato per essere che solo ogni 16 (?) Personaggio è stato utilizzato nel hash per stringhe "lunghe".

Potrebbe essere stato specificato per promuovere l'interoperabilità serializzazione tra le versioni successive di Java, o anche tra i tempi di esecuzione dei diversi fornitori. Sono d'accordo, un programmatore non dovrebbe fare affidamento su una particolare implementazione di hashCode() direttamente, ma cambiando potrebbe potenzialmente rompere un molto di collezioni serializzati.