RFR(s): 8060192: Add default method Collection.toArray(generator)

[David Lloyd]

Yes!  It would be even better for the "toArray(Class)" case if
Class<T> had a "getArrayClass()" method which returned the Class<T[]>,
which would allow:

  return (T[]) Arrays.copyOf(elementData, size, componentType.getArrayClass());

and similar for other array-backed collections.  I never understood
why that method doesn't exist; in fact, am I wrong in understanding
that "Array.newInstance(clazz, 0).getClass()" is effectively the only
way to do this today?

On Thu, Dec 7, 2017 at 7:03 PM, Martin Buchholz <martinrb at google.com> wrote:
> (I'm still trying to love this new API)
>
> The changes to the jsr166 tck are fine.
>
> I'm not convinced that the new implementation for ArrayList is progress.
> The current implementation of toArray(T[]) does
>
>             // Make a new array of a's runtime type, but my contents:
>             return (T[]) Arrays.copyOf(elementData, size, a.getClass());
>
> which does not have to pay the cost of zeroing the array, so is potentially
> faster.  (depends on whether the VM provides cheap pre-zeroed memory?! what
> does jmh say?)
>
> If we're not getting type safety and not getting significantly better
> performance, all we have is a more natural API.  But toArray(IntFunction)
> also seems not very natural to me, and we'll have to live with the
> toArray(new String[0]) wart forever anyways.  (But is it really so bad?)
>  (Maybe toArray(Class<componentType>) is actually more natural?)
>
> On Thu, Dec 7, 2017 at 2:58 PM, Stuart Marks <stuart.marks at oracle.com>
> wrote:
>
>> [Martin: please review changes to the JSR 166 TCK.]
>>
>> Another updated webrev for this changeset:
>>
>>     http://cr.openjdk.java.net/~smarks/reviews/8060192/webrev.2/
>>
>> This includes an override of toArray(IntFunction) in the implementation of
>> Arrays.asList(), as requested by Tagir Valeev.
>>
>> Overrides are also added for various wrapper classes in j.u.Collections.
>> Turns out there's a test test/jdk/java/util/Collections/Wrappers.java
>> that checks to ensure that the wrappers don't inherit any default methods.
>> (This has been a source of bugs in the past.)
>>
>> Significantly, this webrev also includes changes to several tests in the
>> JSR 166 TCK. The issue is that these tests have cases for null handling,
>> where they call
>>
>>     coll.toArray(null)
>>
>> to ensure that NPE is thrown. Given that this method is now overloaded:
>>
>>     toArray(T[])
>>     toArray(IntFunction)
>>
>> passing null is now ambiguous and thus generates a compiler error. I've
>> modified the tests to call toArray((Object[])null) which is a bit of a
>> stopgap. I can't think of anything obviously better to do, though.
>>
>> s'marks
>>



-- 
- DML