logical inconsistence between Set and SortedSet interfaces in Java [closed]

Question

I noticed a logical inconsistence between Set and SortedSet interfaces in Java.

SortedSet recognizes different objects (by equal() method) as equals if they are the same during the comparison, but it is logically incorrect. Comparing of objects should be responsible only for order of objects.

For example: I can have many products and I want to sort them by price. In this case the SortedSet can’t contain different products with the same price: [“salt”,0.5$], [“milk”, 1$], [“bread”, 1$], [“bananas”, 2$] In example above milk will be replaced by bread. In this case the contract of inherited Set interface will be violated, because unequals objects replace each other. I red JavaDoc of SortedSet and know that this behavior well documented, but I think it is a logical failure.

What is your opinion, maybe you have already similar problems with Set and SortedSet?

Answer 1

It is not a logical failure but a property by design. Note that if your comparison algorithm is consistent with equals, a.compareTo(b) == 0 will be equivalent to a.equals(b).

The javadoc is actually very explicit about it:

The behavior of a sorted set is well-defined even if its ordering is inconsistent with equals; it just fails to obey the general contract of the Set interface.

Is that useful?

That actually gives flexibility where you want to reach a specific behaviour. Let's say for example that you want to put strings in your SortedSet and have them sorted ignoring the case, you can use:

Set<String> set = new TreeSet<> (String.CASE_INSENSITIVE_ORDER);

That will achieve the expected result, but this:

set.add("ABC");
set.add("abc");

will only add one string to your set because they will be deemed equal with that specific comparator.