RFR(s): 8060192: Add default method Collection.toArray(generator)
david.lloyd at redhat.com
Fri Dec 8 03:09:13 UTC 2017
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) 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>
>> [Martin: please review changes to the JSR 166 TCK.]
>> Another updated webrev for this changeset:
>> 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
>> to ensure that NPE is thrown. Given that this method is now overloaded:
>> 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.
More information about the core-libs-dev