[
https://issues.apache.org/jira/browse/COLLECTIONS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802154#comment-13802154
]
Thomas Neidhart commented on COLLECTIONS-485:
---------------------------------------------
I do not know exactly why sorted collections have no wildcard type in
java.util.Collections, but I assume it has something to do with the Comparator
being used to sort the item.
One of the requirements is that for no pair of elements in the collection, the
comparator may throw a ClassCastException.
Now, when enabling wildcards for sorted collections one can do the following
(without a warning):
{noformat}
SortedBag<B> bagB = new TreeBag<B>(new Comparator<B>() {
public int compare(B o1, B o2) {
return o1.hashCode() - o2.hashCode();
}
});
bagB.add(new B());
SortedBag<A> bagA =
UnmodifiableSortedBag.<A>unmodifiableSortedBag(bagB);
SortedBag<A> bagA2 = new TreeBag<A>(bagA.comparator());
bagA2.addAll(bagA);
bagA2.add(new C());
{noformat}
This will result in a ClassCastException when you try to add a C object to
bagA2. This is maybe a bit far-fetched, but perfectly valid when allowing
wildcard generics for a SortedBag.
> Collection copy-constructors should accept wildcarded input
> -----------------------------------------------------------
>
> Key: COLLECTIONS-485
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-485
> Project: Commons Collections
> Issue Type: Improvement
> Components: Bag, BidiMap, Collection, List, Map, Set
> Affects Versions: 4.0-alpha1
> Reporter: Hollis Waite
> Attachments: wildcards.patch
>
>
> Many Collection constructors copy input in order to self-populate. For
> convenience (and consistency with standard Java collections library),
> wildcarded parameters should be accepted where possible. Unmodifiable*
> classes might also benefit from less restrictive generic signatures.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
