(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.ma...@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
>
