Loose ends: Collection.toArray(IntFunction<A[]> generator)
Paul Sandoz
paul.sandoz at oracle.com
Fri May 31 00:41:47 PDT 2013
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.
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.
More information about the lambda-libs-spec-experts
mailing list