Consistencia de hashCode () en una cadena Java

El valor de hashCode de una cadena Java se calcula como ( String.hashCode () ):

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

¿Hay alguna circunstancia (por ejemplo, versión de JVM, proveedor, etc.) en la que la siguiente expresión se evaluará como falsa?

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

Actualización n. ° 1: Si afirma que la respuesta es "sí, existen tales circunstancias", entonces dé un ejemplo concreto de cuándo "Esto es una cadena de Java" .hashCode ()! = 586653468. Intente ser tan específico / concreto como sea posible.

Actualización n. ° 2: Todos sabemos que confiar en los detalles de implementación de hashCode () es malo en general. Sin embargo, estoy hablando específicamente sobre String.hashCode (), así que mantenga la respuesta enfocada en String.hashCode (). Object.hashCode () es totalmente irrelevante en el contexto de esta pregunta.

Puedo ver esa documentación desde Java 1.2.

Si bien es cierto que en general no debe confiar en que la implementación de un código hash siga siendo la misma, ahora es un comportamiento documentado, por java.lang.Stringlo que cambiarlo contaría como romper los contratos existentes.

Siempre que sea posible, no debe confiar en que los códigos hash permanezcan igual en todas las versiones, etc., pero en mi opinión java.lang.Stringes un caso especial simplemente porque se ha especificado el algoritmo ... siempre y cuando esté dispuesto a abandonar la compatibilidad con las versiones anteriores Se especificó el algoritmo, por supuesto.

Encontré algo sobre JDK 1.0 y 1.1 y> = 1.2:

En JDK 1.0.xy 1.1.x, la función hashCode para cadenas largas funcionaba muestreando cada enésimo carácter. Esto garantiza que tendrías muchas cadenas de hashing al mismo valor, lo que ralentizaría la búsqueda de Hashtable. En JDK 1.2, la función se ha mejorado para multiplicar el resultado hasta ahora por 31 y luego agregar el siguiente carácter en secuencia. Esto es un poco más lento, pero es mucho mejor para evitar colisiones. Fuente: http://mindprod.com/jgloss/hashcode.html

Algo diferente, porque parece que necesitas un número: ¿qué tal si usas CRC32 o MD5 en lugar de hashcode y estás listo para comenzar? Sin discusiones ni preocupaciones en absoluto ...

No debe confiar en que un código hash sea igual a un valor específico. Solo que devolverá resultados consistentes dentro de la misma ejecución. Los documentos API dicen lo siguiente:

El contrato general de hashCode es:

• Cada vez que se invoca en el mismo objeto más de una vez durante la ejecución de una aplicación Java, el método hashCode debe devolver consistentemente el mismo número entero, siempre que no se modifique la información utilizada en comparaciones iguales sobre el objeto. Este número entero no necesita permanecer consistente de una ejecución de una aplicación a otra ejecución de la misma aplicación.

EDITAR Dado que el javadoc para String.hashCode () especifica cómo se calcula el código hash de String, cualquier violación de esto violaría la especificación de API pública.

Como se dijo anteriormente, en general no debe confiar en que el código hash de una clase permanezca igual. Tenga en cuenta que incluso las ejecuciones posteriores de la misma aplicación en la misma VM pueden producir valores hash diferentes. La función hash de AFAIK the Sun JVM calcula el mismo hash en cada ejecución, pero eso no está garantizado.

Tenga en cuenta que esto no es teórico. La función hash para java.lang.String se cambió en JDK1.2 (el hash anterior tenía problemas con cadenas jerárquicas como URL o nombres de archivo, ya que tendía a producir el mismo hash para cadenas que solo diferían al final).

java.lang.String es un caso especial, ya que el algoritmo de su hashCode () está (ahora) documentado, por lo que probablemente pueda confiar en eso. Todavía lo consideraría una mala práctica. Si necesita un algoritmo hash con propiedades especiales y documentadas, simplemente escriba uno :-).

Otra cuestión (!) De la que preocuparse es el posible cambio de implementación entre versiones tempranas / tardías de Java. No creo que los detalles de implementación estén establecidos, por lo que potencialmente una actualización a una futura versión de Java podría causar problemas.

La conclusión es que no confiaría en la implementación de hashCode().

Quizás pueda resaltar qué problema realmente está tratando de resolver utilizando este mecanismo, y eso resaltará un enfoque más adecuado.

Solo para responder a su pregunta y no para continuar ninguna discusión. La implementación de Apache Harmony JDK parece usar un algoritmo diferente, al menos se ve 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;
}

Armonía Apache

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

No dudes en comprobarlo tú mismo ...

Si le preocupan los cambios y posiblemente las máquinas virtuales incompatibles, simplemente copie la implementación de código hash existente en su propia clase de utilidad y úsela para generar sus códigos hash.

El código hash se calculará en función de los valores ASCII de los caracteres en la cadena.

Esta es la implementación en la clase de cadena es la siguiente

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

Las colisiones en el código hash son inevitables. Por ejemplo, las cadenas "Ea" y "FB" dan el mismo código hash que 2236