P4
A DESCRIPTION OF THE PROBLEM :
The Javadoc for java.lang.Comparable claims that the relation R = {(x, y) such that x.compareTo(y) <= 0} must be a total order (i.e., reflexive, transitive, antisymmetric, and strongly connected). Antisymmetry means that if both a.compareTo(b) <= 0 and b.compareTo(a) <= 0, then a and b are the same element (i.e., references to the same object).
The antisymmetry requirement is unnecessary (e.g., for Arrays.sort()). It is also too strong because, for many core class (such as String and Integer), the corresponding relation R does not satisfy antisymmetry. So, these core classes technically violate the Comparable interface. The Javadoc for java.lang.Comparable (and java.util.Comparator) should be updated to state the relation R needs to satisfy a total preorder (reflexive, transitive, and strongly connected).
The confusion stems from two separate notion of "equality." In a total order, equality means that the two elements are identical (which corresponds to reference equality). This is separate from the notion of equivalence. In this context, a and b are equivalent if a.compareTo(b) == 0. Another way to think about this is that the objects form equivalence classes and these equivalence classes form a total order. But this is not the same as saying R is a total order.
https://en.wikipedia.org/wiki/Total_order
https://en.wikipedia.org/wiki/Weak_ordering#Total_preorders
It might also be worth rewriting the compareTo() requirements in terms of standard mathematical properties (reflexive, transitive, and strongly connected). It is stated somewhat awkwardly right now.
FREQUENCY : always
The Javadoc for java.lang.Comparable claims that the relation R = {(x, y) such that x.compareTo(y) <= 0} must be a total order (i.e., reflexive, transitive, antisymmetric, and strongly connected). Antisymmetry means that if both a.compareTo(b) <= 0 and b.compareTo(a) <= 0, then a and b are the same element (i.e., references to the same object).
The antisymmetry requirement is unnecessary (e.g., for Arrays.sort()). It is also too strong because, for many core class (such as String and Integer), the corresponding relation R does not satisfy antisymmetry. So, these core classes technically violate the Comparable interface. The Javadoc for java.lang.Comparable (and java.util.Comparator) should be updated to state the relation R needs to satisfy a total preorder (reflexive, transitive, and strongly connected).
The confusion stems from two separate notion of "equality." In a total order, equality means that the two elements are identical (which corresponds to reference equality). This is separate from the notion of equivalence. In this context, a and b are equivalent if a.compareTo(b) == 0. Another way to think about this is that the objects form equivalence classes and these equivalence classes form a total order. But this is not the same as saying R is a total order.
https://en.wikipedia.org/wiki/Total_order
https://en.wikipedia.org/wiki/Weak_ordering#Total_preorders
It might also be worth rewriting the compareTo() requirements in terms of standard mathematical properties (reflexive, transitive, and strongly connected). It is stated somewhat awkwardly right now.
FREQUENCY : always