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

[Remi Forax]

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.