Comparator API specs lies...

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.
Furthermore, have a look at the Comparator API 's counterpart, Comparable; you will find a similar statement, but this time it's correct!
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 answered in the other forum.
Please do not crosspost.