Loose ends: Collection.toArray(IntFunction<A[]> generator)

[Brian Goetz]

Of course the test can be changed, that wasn't the point.  The point is the cost of this will be higher than one might initially think since there will almost certainly be JCK tests that have to be changed too.  

On May 31, 2013, at 1:50 AM, Remi Forax wrote:

> On 05/31/2013 09:41 AM, Paul Sandoz wrote:
>> Brian pointed out a incompatibility issue on lambda-dev:
>> 
>>   toArray(null) is now ambiguous and will not compile
>> 
>> This is likely in practice to only affect tests checking the method throws an NPE.
>> 
>> Paul.
> 
> yes,
> and the test can be change by adding a cast.
> 
> Rémi
> 
>> 
>> On May 30, 2013, at 11:18 AM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
>> 
>>> A while ago there was some lively discussion on toArray and we finally settled on the following method in Stream:
>>> 
>>>      <A> A[] toArray(IntFunction<A[]> generator);
>>> 
>>> Due to "noise" of other stuff i think we forgot to discuss whether it is valuable to add a similar default method to Collection (as recently suggested by Peter Levart on the lambda-dev list which motivated this email).
>>> 
>>> 
>>> The functionality can already be achieved with:
>>> 
>>>  c.stream().toArray(String[]::new);
>>> 
>>> but is not likely to be as efficient as the existing concrete Collection.toArray implementations (e.g. see ArrayList.toArray)
>>> 
>>> This is also the way to produce an array in parallel:
>>> 
>>>  c.parallelStream().toArray(String[]::new);
>>> 
>>> where efficiencies can be obtained if the collection is large enough.
>>> 
>>> 
>>> But we could also add to Collection:
>>> 
>>>    default <T> T[] toArray(IntFunction<T[]> generator) {
>>>        return toArray(generator.apply(size()));
>>>    }
>>> 
>>>    c.toArray(String[]::new);
>>> 
>>> Seems like a reasonable thing to do. The sequentially efficiency is retained without the "stink" of using the other toArray method accepting an array instance (of or not of the right length).
>>> 
>>> Paul.
>