Comparator API mistake ???

Question

Dear All
whilst revising for my scjp1.4, which incidetally is taking place tomorrow 06/10/03, I stumbled across what I might define a mistake ( bug is too pretentious ) in the Comparator API specs.
I'd like to quote:
"For example, if one adds two keys a and b such that (a.equals((Object)b) && c.compare((Object)a, (Object)b) != 0) to a sorted set with comparator c, the second add operation will return false (and the size of the sorted set will not increase) because a and b are equivalent from the sorted set's perspective. "
Nothing could be more false than such a statement. I'd invite you to belie my words.
Following is a program that should demonstrate my reasoning:
import java.util.*;
public class OrderingTest {
   public static void main(String[] args) {
      if(args.length != 4) {
         usage();
         System.exit(1);
      int arg1, arg2, arg3, arg4;
      arg1 = Integer.parseInt(args[0]);
      arg2 = Integer.parseInt(args[1]);
      arg3 = Integer.parseInt(args[2]);
      arg4 = Integer.parseInt(args[3]);
      Element e1 = new Element(arg1, arg2);
      Element e2 = new Element(arg3, arg4);
      ElementComp ec = new ElementComp();
      System.out.println("e1: " + e1);
      System.out.println("e2: " + e2);
      Set set1 = new HashSet();
      Set set2 = new TreeSet(); // natural order through the comparable nature of Element
      Set set3 = new TreeSet(ec); // total order by passing a comparator
      set1.add(e1);
      set1.add(e2);
      System.out.println("HashSet: " + set1);
      set2.add(e1);
      set2.add(e2);
      System.out.println("TreeSet: " + set2);
      set3.add(e1);
      set3.add(e2);
      System.out.println("TreeSet: " + set3);
   public static void usage() {
      System.out.println("You need to provide 4 arguments: the first two will passed to e1 constructor, the last two will passed to e2 constructor");
class Element implements Comparable {
   public int i;
   public int j;
   public Element(int i, int j) {
      this.i = i;
      this.j = j;
   public boolean equals(Object o) {
      if(o == null) return false;
      Element e = (Element) o;
      boolean result = i == e.i;
      System.out.println(this + ".equals(" + o + "): " + result);
      return result ;
   public int hashCode() {
      System.out.println( this + ".hashCode() called !");
      return 31 * i;
   public String toString() {
      return "Element@" + super.hashCode() + ": " + i + " " + j;
   public int compareTo(Object o) {
      Element e = (Element) o;
      int result = j == e.j ? 0: j - e.j;
      System.out.println(this + ".compareTo(" + o + "): " + result);
      return result;
class ElementComp implements Comparator {
   public int compare(Object o1, Object o2) {
      Element e1 = (Element) o1;
      Element e2 = (Element) o2;
      int result = e1.j == e2.j ? 0: e1.j - e2.j;
      System.out.println("Comparator.compare(" + o1 + ", " + o2 + "): " + result);
      return result;
}You will find 3 sets: a HashSet, a TreeSet, which uses the comparable nature of Element, and another TreeSet, which avails itself of a comparator in order to sort its elements.
What I would like to prove by this is the following:
HashSet makes use of hashCode() and where necessary of equals(Object o) to make store and to check upon the equality of object.
TreeSet with Comparable does not make use of hashCode() and equals(Object o), but only compareTo(Object o) to store object and and check for their equality.
TreeSet with Comparator does not make use of hashCode() and equals(Object o), bu only compare(Object o1, Object o2) to store object and and check for their equality.
The output of the program demonstrates the last 3 statements.
Now to go back to what the Comparator specs says, if you add two object such that (a.equals((Object)b) && c.compare((Object)a, (Object)b) != 0) you will notice that the second element is indeed added to the Set. I have made sure that hashCode() has been redefined to be consistent with equals(Object o) and that compareTo(Object o) and compare(Object o1, Object o2) to be inconsistent with equals.
Now I am eager to hear from you, all the more since tommorrow I am sitting the scjp 1.4.
thanks for your help in advance
luca iacono

Answer 1

I wouldn't call it an issue of the contract not being fulfilled. The slight inaccuracy ("will not" instead o "may not") occurs in an example of what can go wrong if the user of the class doesn't fulfill his side of the contract. That wording is correct for the current implementation of HashSet, but not for all cases.
The quote you gave was just an example of this statement: "If the ordering imposed by c on S is inconsistent with equals, the sorted set (or sorted map) will behave 'strangely.' In particular the sorted set (or sorted map) will violate the general contract for set (or map), which is defined in terms of equals."
Basically this statement says, "If your Comparator is not consistent with equals, don't expect the sorted set or sorted map to behave like it should." I'm not going to concern myself too much with the fact that it may not always behave badly if I break the rules.