Yes, I understand your point. It is also eloquently formulated in
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4730113.
Maybe try to submit a patch via http://openjdk.java.net/ ?
Regards,
Dave
Johan Compagner wrote:
But now you are completely breaking My contact
My object is an database object
MyObject
{
id
name
}
MyObject is only equals if the id is the same
But now i want a TreeSet that orders by name (sometimes case is
important,sometimes not)
Those things are not the same!
I cant make my object equals on name.. That would break everything else!
And that is just not true
I know TreeSet is a special case, but thats the whole point it should always
just use the comparator with everything.
Then it is jus always clear.
if we revert it
HashSet.removeAll(TreeSet)
now suddenly the comparator of the TreeSet is used to remove things from the
HashSet
That is just plain weird and stupid.
johan
On Thu, Mar 5, 2009 at 18:41, Dave Schoorl <[email protected]> wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
