Migrating methods in Collections

[Doug Lea]

On 12/22/2015 03:01 PM, Brian Goetz wrote:
> Returning back to the short-term goal of migrating the Collections API...

If methods accepting Object arguments can be anyfied, this removes
some methods from your problem table: Collection.{contains(Object),
remove(Object)}, List.{indexOf(Object), lastIndexOf(Object)} and
Map.{containsKey(Object), containsValue(Object), remove(Object)}.

I realize that there are still a bunch of unresolved issues
in pulling this off. But ignoring them for now...

One natural follow-on question is that if we can anyfy contains, why
can't we do so for containsAll(Collection<?>)? And similarly for
removeAll(Collection<?>), retainAll(Collection<?>). In other words,
is this or some variant allowed?
   <any T> boolean containsAll(Collection<T>)

If so, the main remaining questions surround optionality of results,
that I'll answer separately. But there are still others,
List.remove(int index) and Collection.toArray()

Doing nothing about List.remove(index) seems to be legal option.  No
existing code will encounter an ambiguity that is not already present
due to autoboxing (for List<Integer>). New code using or implementing
List<int> will need some way to disambiguate. But I think that some
syntax will be needed to allow anyway.  It might be nice introduce
method removeAt to reduce need to use this syntax, but doesn't seem
necessary?

About the two Collection toArray() methods:

The no-arg version must return Object[]. I don't see how anyfying (in
any way) can guarantee compatible results.  The <T> T[] toArray(T[]
array) version has worse problems: most current implementations use
reflection if the argument array is not big enough (because there is
no syntax for "new T[n]").  I don't see offhand how to compatibly
mangle reflective code.  Plus, the spec explicitly says that if the
array is too large, a null is appended to elements. Null is of course
not a legal value for non-ref types.

I don't see a good alternative to leaving both forms of toArray as-is,
and to box results -- requiring that even custom non-ref
implementations do so. But this suggests that we should find some
other way (possibly in a utility class) to create a val-type array of
elements in a val-type collection.

-Doug