[jira] [Commented] (COLLECTIONS-485) Collection copy-constructors should accept wildcarded input
[ https://issues.apache.org/jira/browse/COLLECTIONS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802678#comment-13802678 ] Thomas Neidhart commented on COLLECTIONS-485: - Yes, you are right with your comments about the head/tail/sub methods. I am still wondering if we should allow wildcards for SortedBag, it can still be dangerous and/or misleading as I tried to point out. The problem with SortedSet is much more obvious, but is in fact closely related to the comparator issue. > 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)
[jira] [Commented] (COLLECTIONS-485) Collection copy-constructors should accept wildcarded input
[ https://issues.apache.org/jira/browse/COLLECTIONS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802300#comment-13802300 ] Hollis Waite commented on COLLECTIONS-485: -- > I do not know exactly why sorted collections have no wildcard type in > java.util.Collections See comments from 10/5. I figured that it's because of the head/tail/sub-methods (which don't exist for Bag implementations). No big deal either way. > 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)
[jira] [Commented] (COLLECTIONS-485) Collection copy-constructors should accept wildcarded input
[
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 bagB = new TreeBag(new Comparator() {
public int compare(B o1, B o2) {
return o1.hashCode() - o2.hashCode();
}
});
bagB.add(new B());
SortedBag bagA =
UnmodifiableSortedBag.unmodifiableSortedBag(bagB);
SortedBag bagA2 = new TreeBag(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)
[jira] [Commented] (COLLECTIONS-485) Collection copy-constructors should accept wildcarded input
[ https://issues.apache.org/jira/browse/COLLECTIONS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800290#comment-13800290 ] Hollis Waite commented on COLLECTIONS-485: -- I believe that BagUtils & UnmodifiableSortedBag can also be updated. > 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)
[jira] [Commented] (COLLECTIONS-485) Collection copy-constructors should accept wildcarded input
[ https://issues.apache.org/jira/browse/COLLECTIONS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800236#comment-13800236 ] Thomas Neidhart commented on COLLECTIONS-485: - Applied patch in r1533984 together with other modifications: * suppress generics warnings * add wildcards to all copy-constructors of collection classes Still need to review packages comparators, functors and keyvalue. > 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)
[jira] [Commented] (COLLECTIONS-485) Collection copy-constructors should accept wildcarded input
[ https://issues.apache.org/jira/browse/COLLECTIONS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13800211#comment-13800211 ] Thomas Neidhart commented on COLLECTIONS-485: - Hi Hollis, thanks for your patch, it looks good after a few minor modifications. Regarding the wildcards, we can only add them in these cases: * copy-constructors where the data is really copied * decorators /classes that are unmodifiable (do not alter the wrapped collection) For the special cases of sorted / ordered collections: * the key type shall be fixed, whereas the value type may be using a wildcard > 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)
[jira] [Commented] (COLLECTIONS-485) Collection copy-constructors should accept wildcarded input
[ https://issues.apache.org/jira/browse/COLLECTIONS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13787207#comment-13787207 ] Hollis Waite commented on COLLECTIONS-485: -- Oh, and in the case of EnumMap, it makes sense that wildcards would be rejected since enums are implicitly final. > 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: CaseInsensitiveMap.patch, 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)
[jira] [Commented] (COLLECTIONS-485) Collection copy-constructors should accept wildcarded input
[ https://issues.apache.org/jira/browse/COLLECTIONS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13787206#comment-13787206 ] Hollis Waite commented on COLLECTIONS-485: -- Ah, I notice that 'Collections.unmodifiableSorted*' also rejects wildcarded keys. I suppose that it depends on whether interface has any methods that require a non-wildcarded parameter (e.g. 'SortedSet.tailSet'). Of course, this constraint can be ignored for methods that would throw UnsupportedOperationException anyway (e.g. 'add'). Want me to update patch accordingly? > 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: CaseInsensitiveMap.patch, 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)
[jira] [Commented] (COLLECTIONS-485) Collection copy-constructors should accept wildcarded input
[ https://issues.apache.org/jira/browse/COLLECTIONS-485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13786984#comment-13786984 ] Sebb commented on COLLECTIONS-485: -- Note: the standard Java classes use wildcards for copy ctors. There are some exceptions with regard to wildcard Map keys. For example: ConcurrentSkipListMap(Map m) and ConcurrentSkipListMap(SortedMap m) Same applies to TreeMap. Also EnumMap(Map m) and EnumMap(EnumMap m) So I wonder whether there are some copy constructors that should not use wildcard keys, for example: BagUtils.unmodifiableBag(final Bag bag) > 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: CaseInsensitiveMap.patch, 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)
