RFR: updated draft API for JEP 269 Convenience Collection Factories

[Vitaly Davidovich]

Apps that are sensitive to allocations will not use these convenience
methods in hot paths, varargs or fixed arg.  They're likely to use them
when the extra allocation wouldn't matter (non sensitive code,
startup/initialization, etc).

sent from my phone
On Nov 6, 2015 1:29 PM, "Stuart Marks" <stuart.marks at oracle.com> wrote:

> On 11/6/15 5:12 AM, Michael Hixson wrote:
>
>> +     static <E> List<E> of(E... es) {
>> +         for (E e : es) {
>> +             Objects.requireNonNull(e);
>> +         }
>> +         // NOTE: this can allow a null element to slip through
>> +         return Collections.unmodifiableList(Arrays.asList(es));
>> +     }
>>
>> Even as a skeletal implementation, this one has to be changed to be
>> truly immutable, right?  It currently returns a view of the (mutable)
>> argument array rather than new storage.  Sorry for not providing a
>> proper test:
>>
>
> Good catch! Funnily I had noticed the TOCTOU case that allowed null
> elements in the array to slip through, but not that the array itself was
> still modifiable from the outside. Anyway, I'll fix this. No worries about
> the test.
>
> Has anyone been able to quantify the advantage of having these
>> overloads as opposed to having the varargs versions only?  Is it a
>> matter of performance?
>>
>> I ask because the overloads seem like warts on the APIs (which is a
>> shame -- List and Set are such important APIs).  I'm imagining a
>> future where:
>>
>> 1. We add these overloads for performance gains now.
>> 2. But they're all skeletal implementations that aren't that perfomant
>> anyway.  Efficient versions don't make it into Java SE 9.  People that
>> care a lot about performance avoid using these ones.
>> 3. A few years later, varargs performance or some other language / VM
>> / compiler-level change renders the overloads obsolete.
>>
>
> Yeah, the overloads seem like warts on the API, though probably necessary
> ones.
>
> At present, and for the forseeable future, varargs calls allocate an array
> on the heap, whereas fixed-args calls do not. I don't know how to quantify
> the difference though. Certainly the cost of allocation and initialization
> is borne in-line. Then there is the cost of collection. Collecting
> short-lived objects is cheap (but not free). There is also the possibility
> of escape analysis eliminating the allocation. This seems unlikely to me;
> certainly not something to be relied upon.
>
> The most likely possible future optimization is "frozen arrays," part of
> the "Arrays 2.0" stuff that John Rose has talked about. This is basically
> about immutable arrays. Here, the possibility is to eliminate the defensive
> copy, if the array created to hold the varargs arguments is made immutable.
> (This will require some adjustment on the callee side, as yet unspecified.)
> There's still an array, though. And a defensive copy would still have to be
> made if the caller passes an actual array, as opposed to a varargs list.
>
> While I can't quantify it, I do think there's an expense to creating the
> varargs array, and there is only a possibility to reduce (but not
> eliminate) its cost in future JDK releases. This cost is entirely avoided
> by fixed-args overloads. (There is the cost of cluttering up the API,
> though.)
>
> Turning to the skeletal vs. optimized implementation, my plan is certainly
> to ensure that the optimized implementations get into JDK 9. Of course,
> plans can change. If the APIs get in without the optimized implementations,
> I think the big attractor will still be the convenience of using these
> static factory methods as opposed to conventional code. They're no slower
> than conventional code, and the space consumed is the same. So I think
> they'll be popular even if the space efficiency benefits aren't there
> initially.
>
> When the optimized implementations do get in, callers will benefit, even
> without recompilation. Thus there is some present value added based on
> potential future benefits.
>
> There is always the set of possible future events that cause something not
> to work out, but I think pursuing the approach I've outlined has a good
> chance of benefiting the platform in the long term.
>
> s'marks
>