Consistência de hashCode () em uma sequência Java

O valor hashCode de uma String Java é calculado como ( String.hashCode () ):

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

Existem circunstâncias (por exemplo, versão da JVM, fornecedor etc.) sob as quais a expressão a seguir será avaliada como falsa?

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

Atualização 1: se você afirmar que a resposta é "sim, existem circunstâncias" - forneça um exemplo concreto de quando "Esta é uma string Java" .hashCode ()! = 586653468. Tente ser o mais específico / concreto que possível.

Atualização 2: Todos sabemos que confiar nos detalhes da implementação de hashCode () é ruim em geral. No entanto, estou falando especificamente sobre String.hashCode () - portanto, mantenha a resposta focada em String.hashCode (). Object.hashCode () é totalmente irrelevante no contexto desta pergunta.

Eu posso ver essa documentação já em Java 1.2.

Embora seja verdade que, em geral, você não deve confiar em uma implementação de código de hash permanecendo a mesma, agora é um comportamento documentado java.lang.String, portanto, alterá-lo contará como quebra de contratos existentes.

Sempre que possível, você não deve confiar em códigos de hash permanecendo o mesmo em todas as versões etc - mas na minha mente java.lang.Stringé um caso especial, simplesmente porque o algoritmo tenha sido especificado ... desde que você está disposto a abandonar a compatibilidade com versões anteriores à algoritmo foi especificado, é claro.

Encontrei algo sobre o JDK 1.0 e 1.1 e> = 1.2:

No JDK 1.0.xe 1.1.x, a função hashCode para Strings longas trabalhava com amostragem de cada enésimo caractere. Isso garante que você tenha muitas strings hash no mesmo valor, diminuindo a velocidade da pesquisa do Hashtable. No JDK 1.2, a função foi aprimorada para multiplicar o resultado até agora por 31 e adicionar o próximo caractere em sequência. Isso é um pouco mais lento, mas é muito melhor para evitar colisões. Fonte: http://mindprod.com/jgloss/hashcode.html

Algo diferente, porque você parece precisar de um número: que tal usar o CRC32 ou MD5 em vez do código de hash e você está pronto - sem discussões e sem preocupações ...

Você não deve confiar em um código de hash igual a um valor específico. Só que ele retornará resultados consistentes dentro da mesma execução. Os documentos da API dizem o seguinte:

O contrato geral do hashCode é:

• Sempre que é invocado no mesmo objeto mais de uma vez durante a execução de um aplicativo Java, o método hashCode deve retornar consistentemente o mesmo número inteiro, desde que nenhuma informação usada em comparações iguais no objeto seja modificada. Esse número inteiro não precisa permanecer consistente de uma execução de um aplicativo para outra execução do mesmo aplicativo.

EDIT Como o javadoc para String.hashCode () especifica como o código de hash de uma String é calculado, qualquer violação disso violaria a especificação pública da API.

Como dito acima, em geral você não deve confiar no código hash de uma classe que permanece o mesmo. Observe que mesmo execuções subsequentes do mesmo aplicativo na mesma VM podem produzir valores de hash diferentes. AFAIK, a função de hash da Sun JVM calcula o mesmo hash em cada execução, mas isso não é garantido.

Observe que isso não é teórico. A função hash para java.lang.String foi alterada no JDK1.2 (o hash antigo teve problemas com cadeias hierárquicas como URLs ou nomes de arquivos, pois tendia a produzir o mesmo hash para cadeias de caracteres que diferiam apenas no final).

java.lang.String é um caso especial, pois o algoritmo de seu hashCode () está (agora) documentado, portanto você provavelmente pode confiar nisso. Eu ainda consideraria uma prática ruim. Se você precisar de um algoritmo de hash com propriedades especiais documentadas, basta escrever um :-).

Outra questão (!) Com que se preocupar é a possível alteração de implementação entre as versões iniciais / tardias do Java. Não acredito que os detalhes da implementação estejam definidos, e potencialmente uma atualização para uma versão futura do Java pode causar problemas.

Resumindo, eu não confiaria na implementação de hashCode().

Talvez você possa destacar qual problema está realmente tentando resolver usando esse mecanismo, e isso destacará uma abordagem mais adequada.

Apenas para responder sua pergunta e não continuar com nenhuma discussão. A implementação do Apache Harmony JDK parece usar um algoritmo diferente, pelo menos parece totalmente diferente:

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;
}

Sinta-se livre para verificar você mesmo ...

Se você estiver preocupado com alterações e possivelmente com VMs incompatíveis, copie a implementação de código de hash existente em sua própria classe de utilitário e use-a para gerar seus códigos de hash.

O hashcode será calculado com base nos valores ASCII dos caracteres na String.

Esta é a implementação na classe String é a seguinte

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

Colisões no código hash são inevitáveis. Por exemplo, as cadeias "Ea" e "FB" fornecem o mesmo código hash que 2236