Comparator doubt
Deepak Jain
Ranch Hand
Posts: 637
posted 8 years ago
Java doc
Result:
DJ
DJ
Deepak
Which i think is correct because
TreeSet<Employee> listSet = new TreeSet<Employee>(new EmployeeAgeComparator());
listSet is created using AgeComparator and for AgeComparator
(new Employee("DJ", 23));
(new Employee("DJ", 24));
Are different objects . But
new Employee("DJ", 23).equals(new Employee("DJ", 24)) is true becuase Employee equals method is based on name and since names are both DJ , Hence both objects are equal . I think the result is correct.
The thing am not understanding the statement from Java doc
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.
a.equals((Object)b) : new Employee("DJ", 23).equals(new Employee("DJ", 24)) is true
c.compare((Object)a, (Object)b) != 0): Age Comparator will return new (new Employee("DJ", 23));
(new Employee("DJ", 24));
as unequal
But the set accepted both the objects. then why does java doc speak otherwise?
Someone please clarify
Caution should be exercised when using a comparator capable of imposing an ordering inconsistent with equals to order a sorted set (or sorted map). Suppose a sorted set (or sorted map) with an explicit Comparator c is used with elements (or keys) drawn from a set S. 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.
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.
Result:
DJ
DJ
Deepak
Which i think is correct because
TreeSet<Employee> listSet = new TreeSet<Employee>(new EmployeeAgeComparator());
listSet is created using AgeComparator and for AgeComparator
(new Employee("DJ", 23));
(new Employee("DJ", 24));
Are different objects . But
new Employee("DJ", 23).equals(new Employee("DJ", 24)) is true becuase Employee equals method is based on name and since names are both DJ , Hence both objects are equal . I think the result is correct.
The thing am not understanding the statement from Java doc
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.
a.equals((Object)b) : new Employee("DJ", 23).equals(new Employee("DJ", 24)) is true
c.compare((Object)a, (Object)b) != 0): Age Comparator will return new (new Employee("DJ", 23));
(new Employee("DJ", 24));
as unequal
But the set accepted both the objects. then why does java doc speak otherwise?
Someone please clarify
SCJP, SCWCD, SCBCD
posted 8 years ago
Well as far as I get it, the example you gave is perfect to see why the javadoc says that the comparator should be compatible with equals. In your example you are able to add two objects to a TreeSet which are equal as per equals method, but are different according to the compare method. The output is also correct. But when you use
listSet.get(new Employee("DJ", 23));
and
listSet.get(new Employee("DJ", 24));
then the "strange behavior" that javadoc mentions comes into action. Now you have two keys which are basically the same according to the equals method. So now the get method might match the same key both the time or might match different keys both the time...
listSet.get(new Employee("DJ", 23));
and
listSet.get(new Employee("DJ", 24));
then the "strange behavior" that javadoc mentions comes into action. Now you have two keys which are basically the same according to the equals method. So now the get method might match the same key both the time or might match different keys both the time...
SCJP 6  SCWCD 5  Javaranch SCJP FAQ  SCWCD Links
Deepak Jain
Ranch Hand
Posts: 637
posted 8 years ago
Could you demonstrate
"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."
Using the example i gave..
Further
listSet.get(new Employee("DJ", 23));
and
listSet.get(new Employee("DJ", 24));
TreeSet and Set does not support get methods.
"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."
Using the example i gave..
Further
listSet.get(new Employee("DJ", 23));
and
listSet.get(new Employee("DJ", 24));
TreeSet and Set does not support get methods.
SCJP, SCWCD, SCBCD
posted 8 years ago
Sorry Deepak, I gave my example according to TreeMap that is why I used the get method. Anyways you are right that if (a.equals((Object)b) && c.compare((Object)a, (Object)b) != 0), then the second add operation will return true and size of the set WILL increase. Lets see if there is any expert opinions on this...
SCJP 6  SCWCD 5  Javaranch SCJP FAQ  SCWCD Links
siraj siddiqui
Greenhorn
Posts: 11
posted 8 years ago
Deepak i think there is some mistake in the quote that you have posted.
Here is the quote that you have posted
"Caution should be exercised when using a comparator capable of imposing an ordering inconsistent with equals to order a sorted set (or sorted map). Suppose a sorted set (or sorted map) with an explicit Comparator c is used with elements (or keys) drawn from a set S. 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.
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."
But when i saw the comparator interface in the java docs it is like this
" Caution should be exercised when using a comparator capable of imposing an ordering inconsistent with equals to order a sorted set (or sorted map). Suppose a sorted set (or sorted map) with an explicit comparator c is used with elements (or keys) drawn from a set S. 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.
For example, suppose one adds two elements a and b such that (a.equals(b) && c.compare(a, b) != 0) to an empty TreeSet with comparator c. The second add operation will return true (and the size of the tree set will increase) because a and b are not equivalent from the tree set's perspective, even though this is contrary to the specification of the Set.add method."
Here is the quote that you have posted
"Caution should be exercised when using a comparator capable of imposing an ordering inconsistent with equals to order a sorted set (or sorted map). Suppose a sorted set (or sorted map) with an explicit Comparator c is used with elements (or keys) drawn from a set S. 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.
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."
But when i saw the comparator interface in the java docs it is like this
" Caution should be exercised when using a comparator capable of imposing an ordering inconsistent with equals to order a sorted set (or sorted map). Suppose a sorted set (or sorted map) with an explicit comparator c is used with elements (or keys) drawn from a set S. 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.
For example, suppose one adds two elements a and b such that (a.equals(b) && c.compare(a, b) != 0) to an empty TreeSet with comparator c. The second add operation will return true (and the size of the tree set will increase) because a and b are not equivalent from the tree set's perspective, even though this is contrary to the specification of the Set.add method."
Deepak Jain
Ranch Hand
Posts: 637
siraj siddiqui
Greenhorn
Posts: 11
posted 8 years ago
Sorry Deepak but i have not invertared the sentence.Imfact that is what i have in javadocs[1.6]
The second add operation will return true (and the size of the tree set will increase) because a and b are not equivalent from the tree set's perspective, even though this is contrary to the specification of the Set.add method.
The second add operation will return true (and the size of the tree set will increase) because a and b are not equivalent from the tree set's perspective, even though this is contrary to the specification of the Set.add method.
Punit Singh
Ranch Hand
Posts: 952
What are you doing? You are supposed to be reading this tiny ad!
the new thread boost feature brings a LOT of attention to your favorite threads
https://coderanch.com/t/674455/ThreadBoostfeature
