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

Jonathan Bluett-Duncan jbluettduncan at gmail.com
Thu Dec 7 23:50:17 UTC 2017

Hi Stuart,

Looking over http://cr.openjdk.java.net/~smarks/reviews/8060192/webrev.2/src/java.base/share/classes/java/util/ArrayList.java.cdiff.html, I'm wondering if the method ArrayList.toArray(IntFunction) should have an @Override to make it clear that it's overriding the default method in Collection. What do you think?

Cheers, Jonathan

On 7 December 2017 at 22:58, 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

More information about the core-libs-dev mailing list