On 04/12/2014 08:41 AM, Dipanjan Laha wrote: > On Sat, Apr 12, 2014 at 1:04 AM, Thomas Neidhart > <thomas.neidh...@gmail.com>wrote: > >> On 04/11/2014 05:52 AM, Dipanjan Laha wrote: >>> 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. >> >> usually the decorators delegate the call to equals to the decorated >> collection, which means we can not guarantee the symmetry requirement >> for all possible decorated collections. >> >> The only way to be on the safe-side would be to delegate to >> Object#equals(). >> > > If we do this, it would break a lot of existing functionality (and needless > to say tests). > Joshua Bloch says in Effective Java that "There is no way to extend an > instantiable class and add a value component while preserving the equals > contract, unless you are willing to forgo the benefits of object-oriented > abstraction" . So imho, I think we should let this be even if this breaks > equals symmetry
I agree that we can not change it like that as it would potentially break existing code. Otoh, I do not think the problem at hand is directly related to the one stated by Joshua Bloch, as in this case we do not add additional values or necessarily deal with sub-classes. The problem comes from the fact that different collection classes do different types of equality checks, and even further restrict their equals method to specific types of collections. This issue was already reported a while ago after executing similar automated tests on collections (probably even with the same tool). At the time I decided to ignore it, which was probably a mistake. So I would suggest that we at least document what the equals method of the respective decorators actually does, with a link to the mentioned CollectionUtils method if one wants to be sure to do a real value comparison. Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
