Coerenza di hashCode () su una stringa Java

Il valore hashCode di una stringa Java viene calcolato come ( String.hashCode () ):

s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]

Vi sono circostanze (ad esempio versione JVM, fornitore, ecc.) In base alle quali la seguente espressione verrà valutata come falsa?

boolean expression = "This is a Java string".hashCode() == 586653468

Aggiornamento n. 1: se affermi che la risposta è "sì, ci sono circostanze del genere" - per favore fai un esempio concreto di quando "Questa è una stringa Java" .hashCode ()! = 586653468. Prova ad essere specifico / concreto il più possibile.

Aggiornamento n. 2: Sappiamo tutti che fare affidamento sui dettagli di implementazione di hashCode () è generalmente negativo. Tuttavia, sto parlando specificamente di String.hashCode () - quindi ti preghiamo di mantenere la risposta focalizzata su String.hashCode (). Object.hashCode () è totalmente irrilevante nel contesto di questa domanda.

Vedo quella documentazione fin da Java 1.2.

Mentre è vero che in generale non dovresti fare affidamento sul fatto che un'implementazione del codice hash rimanga la stessa, ora è un comportamento documentato java.lang.String, quindi cambiarlo conterebbe come rompere i contratti esistenti.

Ove possibile, non dovresti fare affidamento sul fatto che i codici hash rimangano gli stessi tra le versioni ecc., Ma nella mia mente java.lang.Stringè un caso speciale semplicemente perché l'algoritmo è stato specificato ... purché tu sia disposto ad abbandonare la compatibilità con le versioni prima del l'algoritmo è stato specificato, ovviamente.

Ho trovato qualcosa su JDK 1.0 e 1.1 e> = 1.2:

In JDK 1.0.xe 1.1.x la funzione hashCode per stringhe lunghe ha funzionato campionando ogni ennesimo carattere. Ciò garantisce che molte stringhe abbiano lo stesso valore, rallentando così la ricerca Hashtable. In JDK 1.2 la funzione è stata migliorata per moltiplicare il risultato finora per 31, quindi aggiungere il carattere successivo in sequenza. Questo è un po 'più lento, ma è molto meglio per evitare le collisioni. Fonte: http://mindprod.com/jgloss/hashcode.html

Qualcosa di diverso, perché sembra che tu abbia bisogno di un numero: che ne dici di usare CRC32 o MD5 invece di hashcode e sei a posto - nessuna discussione e nessuna preoccupazione ...

Non devi fare affidamento sul fatto che un codice hash sia uguale a un valore specifico. Solo che restituirà risultati coerenti all'interno della stessa esecuzione. I documenti API dicono quanto segue:

Il contratto generale di hashCode è:

• Ogni volta che viene invocato sullo stesso oggetto più di una volta durante un'esecuzione di un'applicazione Java, il metodo hashCode deve restituire costantemente lo stesso numero intero, a condizione che non vengano modificate le informazioni utilizzate nei confronti uguali sull'oggetto. Questo numero intero non deve rimanere coerente da un'esecuzione di un'applicazione a un'altra esecuzione della stessa applicazione.

EDIT Poiché javadoc per String.hashCode () specifica come viene calcolato il codice hash di una stringa, qualsiasi violazione di ciò violerebbe la specifica dell'API pubblica.

Come detto sopra, in generale non dovresti fare affidamento sul fatto che il codice hash di una classe rimanga lo stesso. Si noti che anche le esecuzioni successive della stessa applicazione sulla stessa macchina virtuale possono produrre valori hash diversi. AFAIK la funzione hash di Sun JVM calcola lo stesso hash ad ogni corsa, ma ciò non è garantito.

Si noti che questo non è teorico. La funzione hash per java.lang.String è stata modificata in JDK1.2 (il vecchio hash aveva problemi con stringhe gerarchiche come URL o nomi di file, poiché tendeva a produrre lo stesso hash per stringhe che differivano solo alla fine).

java.lang.String è un caso speciale, poiché l'algoritmo del suo hashCode () è (ora) documentato, quindi probabilmente puoi fare affidamento su questo. Lo considererei ancora una cattiva pratica. Se hai bisogno di un algoritmo hash con proprietà speciali e documentate, basta scriverne uno :-).

Un altro (!) Problema di cui preoccuparsi è il possibile cambio di implementazione tra le versioni precedenti / successive di Java. Non credo che i dettagli dell'implementazione siano impostati in pietra, e quindi potenzialmente un aggiornamento a una versione futura di Java potrebbe causare problemi.

In conclusione, non farei affidamento sull'implementazione di hashCode().

Forse puoi evidenziare quale problema stai effettivamente cercando di risolvere usando questo meccanismo, e questo metterà in evidenza un approccio più adatto.

Solo per rispondere alla tua domanda e non continuare nessuna discussione. L'implementazione di Apache Harmony JDK sembra utilizzare un algoritmo diverso, almeno sembra totalmente diverso:

Sun JDK

public int hashCode() {
    int h = hash;
    if (h == 0) {
        int off = offset;
        char val[] = value;
        int len = count;

        for (int i = 0; i < len; i++) {
            h = 31*h + val[off++];
        }
        hash = h;
    }
    return h;
}

Apache Harmony

public int hashCode() {
    if (hashCode == 0) {
        int hash = 0, multiplier = 1;
        for (int i = offset + count - 1; i >= offset; i--) {
            hash += value[i] * multiplier;
            int shifted = multiplier << 5;
            multiplier = shifted - multiplier;
        }
        hashCode = hash;
    }
    return hashCode;
}

Sentiti libero di controllarlo tu stesso ...

Se sei preoccupato per le modifiche e forse per le VM incompatibili, copia l'implementazione dell'hashcode esistente nella tua classe di utilità e usala per generare i tuoi hashcode.

L'hashcode verrà calcolato in base ai valori ASCII dei caratteri nella stringa.

Questa è l'implementazione nella classe String è la seguente

public int hashCode() {
    int h = hash;
    if (h == 0 && value.length > 0) {
        hash = h = isLatin1() ? StringLatin1.hashCode(value)
                              : StringUTF16.hashCode(value);
    }
    return h;
}

Le collisioni nell'hashcode sono inevitabili. Ad esempio, le stringhe "Ea" e "FB" forniscono lo stesso codice hash di 2236