I bit confused here. Are we all in agreement with Peter's example:
> I live in hope that CollectionUtils behaves as equivalent as possible to
> java.util.Collection . Given two collections
>
> Collection _c = new ArrayList();
> _c.add(("a").toUpperCase());
> _c.add("X");
> Collection _d = new LinkedList();
> _d.add(("a").toUpperCase());
> _d.add("Y");
>
> what should be the intersection of them both? I would suggest a collection
> containing one element "A". Do you agree?
I do. That's the current behavior of CollectionUtils.intersection. I've
just added a unit test
(TestCollectionUtils.testIntersectionUsesMethodEquals) that shows that the
intersection of some collections { a }, { b }, where a.equals(b) but a !=
b, is in fact the collection { c } where c.equals(a) and c.equals(b) (and,
somewhat coincidently, c == a or c == b, but not both).
The full test can be seen at:
<http://cvs.apache.org/viewcvs/jakarta-commons/collections/src/test/org/apache/commons/collections/TestCollectionUtils.java.diff?r1=1.12&r2=1.13&diff_format=h>
This test passes.
Is there a case for some other behavior? I'm not sure where operator==
enters into this.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
