ArrayFactory SAM type / toArray

[Joshua Bloch]

Aleksey,

On Thu, Sep 20, 2012 at 3:25 AM, Aleksey Shipilev <
aleksey.shipilev at oracle.com> wrote:

>
> Begging to differ here. Isn't the API the middleground for _both_ user
> convenience and library performance? Most users choose API for the
> consistency, but more and more users these days ask themselves from the
> ground up about the expected performance.
>

Yeah, I believe we're in complete agreement here.


> This, by the way, makes me thinking: if ArrayFactory contract is relaxed
> to say "provides the candidate for storing the values", i.e. dropping
> the referential equality out of the question, we can then do pre-cached
> returns from toArray for small collections, and thus completely spare
> the allocations on some of the code paths.
>

Your subsequent observation (that all zero-length arrays are immutable, and
all nonzero-length arrays are mutable, hence not sharable) is correct.
 That said, Donald's suggestion (Class.emptyArray and Class.newArray(T))
seems like a decent middle ground.  It's (in all likelihood) faster than
reflection and factory methods, and has smaller "conceptual surface area."
 It's too bad that it shines a light on two problems in Java's type system:
the impedance mismatch between arrays and generics, and between primitives
and generics.  But those problems will haunt us forever (unless we decide
to redo the type system and break compatibility in a major way).  They're
just a fact of life, given the design that we adopted for generics.

    Josh