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
