Hi, The only issue here is then Collection's equals implementation would need to check individually whether the Collection also implements List, Set or Bag (more such interfaces may come up in the future). This is kind of a hard coupling between Collections equals and other implementations which will become very difficult to maintain. The other option would be to fall back to Object#equals (a lot of Java collection classes do that), but that would mean that value based comparison won't be possible. Maybe there's a better way to solve this, but I can't think of anything right now.
Regards Dipanjan On Thu, Apr 10, 2014 at 1:11 PM, Julien Aymé <julien.a...@gmail.com> wrote: > Hi, > > As specified by Collection#equals(Object) javadoc ( > > http://docs.oracle.com/javase/7/docs/api/java/util/Collection.html#equals(java.lang.Object) > ), equals must be symmetric. > That's why Collection.equals(List) must return false, as well as > Collection.equals(Set), while Collection.equals(Collection) may return > true if it contains the same values. > > My 2 cents, > Regards, > Julien > > 2014-04-10 11:27 GMT+04:00 Dipanjan Laha <dipanja...@gmail.com>: > > Hello, > > > > I checked the equals symmetry mismatch issue in > > https://issues.apache.org/jira/browse/COLLECTIONS-512. I haven't checked > > the hascode mismatch or any other issue yet. > > > > The test in BugReport1_1.java initializes AbstractIterableGetMapDecorator > > which is meant to be abstract but is not. So imho we should ignore this > > test and in turn make AbstractIterableGetMapDecorator abstract. > > > > The test1 of BugReport1.java has something quite interesting. The equals > > symmetry is failing here between objects returned by > > CollectionUtils.emptyCollection (returns an UnmodifiableCollection) and > > CollectionUtils.subtract (returns an ArrayList). > > > > So basically UnmodifiableCollection.equals(ArrayList) returns true and > > ArrayList.equals(UnmodifiableCollection) returns false. This is happening > > because UnmodifiableCollection internally decorates an ArrayList and the > > equals passes. But the ArrayList.equals(UnmodifiableCollection) fails as > > the equals of ArrayList checks whether the passed in object is instance > of > > List. > > I am not exactly sure what the behavior should be. The root problem is > > Collection.equals(List) would pass whereas List.equals(Collection) would > > always fail when the Collection's implementation does not implement a > List. > > A similar problem exists with Set. So should the equals symmetry be > ignored > > here? Please share your opinions. > > > > Regards > > Dipanjan > > > > > > On Thu, Apr 10, 2014 at 10:24 AM, Cyrille Artho <c.ar...@aist.go.jp> > wrote: > > > >> Dear developers, > >> We have found several issues in Apache commons collections, version > >> 4.0. We have grouped similar issues into one bug report (as the root > cause > >> may be in one place or the same problem in a few isolated places). > >> > >> Here are the direct links; please look at the bug tracker for details. > We > >> would appreciate feedback on whether these test reveal real issues, and > on > >> how useful they are to confirm/understand the issues. > >> > >> * equals/hashCode mismatch: > >> > >> https://issues.apache.org/jira/browse/COLLECTIONS-512 > >> > >> * NullPointerException in transformations: > >> > >> https://issues.apache.org/jira/browse/COLLECTIONS-513 > >> > >> (This may be intended except that according to the documentation, > >> IllegalArgumentException should probably be thrown.) > >> > >> * NullPointerException in mapBackedSet: > >> > >> https://issues.apache.org/jira/browse/COLLECTIONS-514 > >> > >> Either the documentation or the code needs a minor update here. > >> > >> * A strange ClassCastException: > >> > >> https://issues.apache.org/jira/browse/COLLECTIONS-515 > >> > >> * NullPointerException in MapUtils.toProperties: > >> > >> https://issues.apache.org/jira/browse/COLLECTIONS-516 > >> > >> This is probably a corner case that can be dealt with more gracefully. > >> -- > >> Regards, > >> Cyrille Artho - http://artho.com/ > >> Those who will not reason, are bigots, those who cannot, > >> are fools, and those who dare not, are slaves. > >> -- George Gordon Noel Byron > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
