When you ask the hashset if it contains that object (checking whether or not to remove) it will say that it doesn't contain it because it's not the same object (you didn't override equals and hashCode). That's the whole issue here.
On Mar 5, 2009 8:06 AM, "Johan Compagner" <[email protected]> wrote: yes i know but the TreeSet does also say that in the javadoc that it is an exception because of the Comparator And they could really just make it a black box. The only things they just need to fix then is the removeAll and retainAll methods Why the removeAll iterates by default over itself and ask for a contains on the other and then removes itself again is beyond me I wouldnt never implement it that way. Why would you do that in the first place? It wouldnt come into my mind to do it like that besides that AbstractSet.removeAll makes it even worse: public boolean removeAll(Collection<?> c) { boolean modified = false; if (size() > c.size()) { for (Iterator<?> i = c.iterator(); i.hasNext(); ) modified |= remove(i.n... } else { for (Iterator<?> i = iterator(); i.hasNext(); ) { if (c.contains(i.next())) { i.remove(); modified = true; } } } return modified; } see partly it does what i expect to happen (the if) but what sun wants to happen is the else.. So now we just have 2 behaviors depending on what size the collection has... nice.. On Thu, Mar 5, 2009 at 13:58, Maarten Bosteels <[email protected] >wrote: > It is in the javadoc for Comparator > > "Caution should be exercised when using a comparator capa... > pointbreak%[email protected] <pointbreak%[email protected]>< pointbreak%[email protected]<pointbreak%[email protected]> > > >> > > > > wrote: > > > > > >> Sorry, I have to correct myself. According to the API-docs, the > c... > pointbreak%[email protected] <pointbreak%[email protected]>< pointbreak%[email protected]<pointbreak%[email protected]> > > >>> > > >> wrote: > > >> > You are missing the point. With a string it will work, because the > > ...
