Ha senso per uguali e confronti Per essere incoerente?

Question

Voglio rendere una classe utilizzabile in SortedSet | SortedMap.

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

    //... 
} 

Le istanze della classe devono essere ordinate in base alla relativa proprietà.
Tuttavia, non voglio che le istanze con lo stesso nome siano considerate uguali.

Quindi un contenuto di SortedSet sarà simile a a, a, a, b, c.
(Normalmente, SortedSet avrebbe consentito solamente a, b, c)

Innanzitutto: è questo (filosoficamente) consistente?

Se è così, devo aspettare un comportamento imprevedibile, quando lo faccio non esclusione equals(...) e hashCode()?

Edit:
Mi dispiace, la mia domanda sembra incoerente:
Voglio mettere più "uguale" valori all'interno di un set , che non consente questo dal concept.
Quindi, per favore non rispondere più alla mia domanda.
Grazie a tutti coloro che hanno già risposto.

Answer 1

Lascia che ti faccia una domanda: ha senso avere a.compareTo(b) restituire 0 e a.equals(b) restituire false?

Vorrei utilizzare un Comparator<MyClass> invece. Questo è il motivo per cui tutte le implementazioni SortedMap/SortedSet che conosco consentono di passare in un Comparator alla creazione.

Answer 2

Effective Java raccomanda che se non implementare compareTo coerente con equals si dovrebbe indicare chiaramente così:

La lingua consigliata è "Nota: Questa classe ha un ordinamento naturale che è incompatibile con eguali. "

Answer 3

Basta mettere questo codice nel metodo equals e non lo mai pensato di nuovo:

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

Answer 4

Dal Javadoc per Paragonabile

Si raccomanda vivamente (anche se non richiesto) che gli ordinamenti naturali siano coerenti con gli uguali.Questo è così perché insiemi ordinati (e ordinati mappe) senza comparatori espliciti comportano "stranamente" quando vengono utilizzati con elementi (o chiavi) la cui ordinamento naturale è incompatibile con uguale

Se vuoi avere un confronto Per quanto sia incoerente con equals(), si consiglia di utilizzare un comparatore esplicito, fornendo una classe che implementa Comparator.

Se è così, devo aspettare un comportamento imprevedibile, quando non sovrascrive equals (...) e hashCode()?

Si dovrebbe comunque eseguire l'override di equals() e hashcode(). Indipendentemente dal fatto che equals() e hashcode() siano coerenti con compareTo è una questione diversa.