ArrayFactory SAM type / toArray
josh at bloch.us
Wed Sep 19 15:33:42 PDT 2012
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); // 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
More information about the lambda-libs-spec-observers