No that isnt the issue here Because i dont ask in my point of view anything of the hashset!
Why would this result in something asking the hashset (asking like that it has to use the hash or equals things on things that are in the TreeSet)? TreeSet.removeAll(HashSet) why? It should just iterate over all what is in the HashSet and call remove on the TreeSet with every element that is in the iterator of the HashSet The workaround i do now in the code is doing that my self (iterating of the HashSet and calling remove() on the TreeSet) johan On Thu, Mar 5, 2009 at 15:50, James Carman <[email protected]>wrote: > 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]> > >< > 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]> > >< > 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 > > ... >
