ArrayFactory SAM type / toArray

Sam Pullara sam at sampullara.com
Wed Sep 19 15:58:05 PDT 2012


I think that we should not only use this proposal but also make it
work for .into() so i can pass in a lambda that gets a size if it is
available:

interface CollectionFactory<T extends Collection> {
  T create(int minSize);
}

Stream.into(CollectionFactory<T> factory)

stream.into(n -> new ArrayList(n))

I don't think I have ever NOT created mine to be the right size and
type with the current API.

Sam

On Wed, Sep 19, 2012 at 3:33 PM, Joshua Bloch <josh at bloch.us> wrote:
> Brian,
>
> On Wed, Sep 19, 2012 at 3:13 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>>
>>> I don't find these arguments convincing.  There's no race (any more than
>>> there is for any bulk operation) as the allocation is done by the object
>>> itself.  The allocation stuff is pretty much a red herring: most users
>>> don't preallocate the array. So it seems to me that using factories here
>>> might amount to needless complexity and inconsistency.
>>
>>
>> I agree with you that most users don't pre-allocate the array.  Which
>> makes the existing form of toArray even more unfortunate!  Because then the
>> allocation always involves multiple reflective calls.  (Some of which are
>> sometimes optimized by some VMs in some conditions, but none of which are
>> always optimized by all VMs in all conditions.)  So the performance will
>> always be worse in the toArray(T[]) formulation.
>
>
> Performance is typically irrelevant.  In the rare cases where it isn't, you
> preallocate.  Warping API for performance is generally a bad idea.
>
>>
>>
>> We're creating a new API here.
>
>
> Yeah, I haven't exactly been keeping up, so I don't know the context. That
> said, the current toArray APIs are pretty good.  I've never heard anyone
> complain about them.
>
>>
>>
>> Here are what the client callsites might look like in various cases:
>>
>>  // status quo
>>  Foo[] foos = ...toArray(new Foo[0]);            // ugh reflection
>
>
> I agree that the above is a bit nasty. I think some syntactic sugar, perhaps
> coupled with a cache of commonly used 0-length arrays might be a good idea.
>
>     Josh
>


More information about the lambda-libs-spec-experts mailing list