Sorry Pointbreak, I did not change the Comparators. They are identical
to Johan's example. All I did was to add the equals() and hascode()
methods, aligning the equals with the Comparator, as described by the specs.
Indeed, maybe I am missing Johan's point. But early in this thread Johan
described his point as "we have to know the implementations" and
illustrated that with the Set-example. My point is that you don't have
to know the implementations when all contracts are fulfilled correctly.
And I tried to point out in his example, that the contracts are not
fulfilled correctly.
But now I think Johan tries to make the point that the TreeSet is
useless given the contracts, because the Comparator and equals() method
must be compatible. Or he tries to make the point that the TreeSet
implementation is broken and the specification must be changed. I'm not
sure. I can sympathize with both. But I am glad he pointed out the
problems with TreeSet, because I wasn't aware of them.
Pointbreak wrote:
Dave, you are missing the point completely. The issue raised by Johan is
that if you call TreeSet.removeAll(otherSet), then in some cases the
comperator/equals contract of otherSet is used, in other cases the
comperator/equals contract of the treeset. Which is a bit strange, and
even by Sun considered a bug (although low priority). You are just
making both comperators the same, which of course will not demonstrate
this problem. Make the comperator of the TreeSet use str.compareTo
instead of compareToIgnoreCase, while keeping your implementation of
MyObject the same, and you will have the same problem that Johan
illustrated.
On Thu, 05 Mar 2009 16:51 +0100, "Dave Schoorl" <[email protected]>
wrote:
I do understand your point. However you are dealing with multiple
contracts and not all of them are satisfied. And sometimes contracts are
conflicting and it is impossible to meet all contracts, but I believe
this is not the case in your scenario.
A TreeSet is an implementation of a Set and must obey the Set contract.
Adding order to the Set should not break the Set contract, because if I
have a Set, I should not be concerned with the implementation details
(is it a TreeSet or a HashSet or whatever). I believe the Set contract
takes precedence over the Comparator contract, but in your case, by
providing an equals method to MyObject that is in line with the
Comparator, there still is no problem. See the code below, where
MyObject implements the equals method with by comparing case insensitive:
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
