¿Tiene sentido que equals y compareTo sean inconsistentes?

Question

Quiero hacer una clase utilizable en SortedSet | SortedMap.

class MyClass implements Comparable<MyClass>{ 
    // the only thing relevant to comparisons: 
    private final String name; 

    //... 
} 

Las instancias de la clase 'se deben ordenar por su propiedad de nombre.
Sin embargo, no deseo que las instancias igualmente nombradas se consideren iguales.

Así que un contenido SortedSet se vería como a, a, a, b, c.
(Normalmente, SortedSet sólo permitiría a, b, c)

En primer lugar: ¿es esto (filosóficamente) consistente?

Si es así, ¿tengo que esperar un comportamiento impredecible, cuando no anulación equals(...) y hashCode()?

Editar:
Lo siento, mi pregunta parece inconsistente:
quiero poner múltiples valores "igual" dentro de un conjunto , que no permite este por concepto.
Entonces, por favor no responda mi pregunta más.
Gracias a todos los que ya respondieron.

Answer 1

Déjame hacerte una pregunta: ¿tiene sentido tener a.compareTo(b) devolver 0 y a.equals(b) devolver false?

Yo usaría un Comparator<MyClass> en su lugar. Esta es la razón por la cual todas las implementaciones de SortedMap/SortedSet que conozco le permiten pasar en un Comparator en la creación.

Answer 2

Effective Java recomienda que si no se implementa compareTo consistente con equals deberá indicar claramente para:

El idioma recomendado es "Nota: Esta clase tiene un orden natural que es incompatible con los iguales. "

Answer 3

Sólo hay que poner este código en el método es igual y no te ocurra pensar en ello de nuevo:

public boolean equals(Object obj) { 
    if (this == obj) return true; 
    if (!(obj instanceof MyClass)) return false; 
    return 0 == this.compareTo((MyClass) obj); 
} 

Answer 4

Desde el Javadoc para Comparable

Es muy recomendable (aunque no requerido) que los ordenamientos naturales sean consistentes con iguales.Esto es así porque los conjuntos ordenados (y ordenados mapas) sin comparadores explícitas comportan "extrañamente" cuando se utilizan con elementos (o teclas) cuyos ordenamiento natural es incompatible con iguales

Si quiere tener CompareTo inconsistente con equals(), se recomienda que utilice un comparador explícito al proporcionar una clase que implementa Comparator.

Si es así, ¿debo esperar un comportamiento impredecible, cuando no anulo equals (...) y hashcode()?

Aún debe reemplazar equals() y hashcode(). Si o no iguales() y hashcode() son consistentes con compareTo es una cuestión diferente.