commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Neidhart (JIRA)" <>
Subject [jira] [Commented] (COLLECTIONS-424) Surprising exception by CompositeSet in a situation where CompositeCollection works fine
Date Thu, 20 Sep 2012 18:26:07 GMT


Thomas Neidhart commented on COLLECTIONS-424:


thanks for providing the patch, but unfortunately I am not sure if it goes into the right
direction. Constraining a CompositeCollection to just one specific collection type is against
the idea of the class (to provide a composite interface for a set of collections). Also the
type safety for the element type is lost due to the fact that CompositeCollections extends

Tbh, I am more in favor of rejecting this issue or removing the inheritance to CompositeCollection
in CompositeSet as there is no real need for it apart from code re-use.
> Surprising exception by CompositeSet in a situation where CompositeCollection works fine
> ----------------------------------------------------------------------------------------
>                 Key: COLLECTIONS-424
>                 URL:
>             Project: Commons Collections
>          Issue Type: Bug
>          Components: Set
>    Affects Versions: 3.2.1
>         Environment: All environments
>            Reporter: Michael Pradel
>         Attachments: collections424.patch
> We have a method that uses a CompositeCollection. Here's a simplified version of it:
>   void m(CompositeCollection coll) {
>     coll.addComposited(new TreeBag());
>   }
> It works fine when the argument is a CompositeCollection, but it throws an exception
when the argument is a CompositeSet. E.g.:
>   m(new CompositeCollection());  // OK
>   m(new CompositeSet());         // IllegalArgumentException
> Although the exception is documented in CompositeSet, this behavior is very surprising.
Is there a way to have m() accept CompositeCollections without running into this exception?
The only solution that comes to my mind is to dynamically check the type of 'coll' in m(),
but this is a rather nasty work-around.
> A better solution may be to make the genericity of CompositeCollection explicit by adding
a type parameter:
>   class CompositeCollection<T extends Collection> {
>     void addComposited(T c) { /* .. */ }
>   }
>   class CompositeSet extends CompositeCollection<Set> {
>     @Override void addComposited(Set c) { /* .. */ }
>   }
> This way, users of CompositeCollection must choose the kind of collections that can be
composed and will not encounter surprises, such as the above.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message