RFC: draft API for JEP 269 Convenience Collection Factories (original) (raw)

Remi Forax forax at univ-mlv.fr
Sat Oct 10 08:52:18 UTC 2015

----- Mail original -----

De: "Stuart Marks" <stuart.marks at oracle.com> À: "Stephen Colebourne" <scolebourne at joda.org> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net> Envoyé: Samedi 10 Octobre 2015 01:11:09 Objet: Re: RFC: draft API for JEP 269 Convenience Collection Factories

On 10/9/15 6:11 AM, Stephen Colebourne wrote: > On 9 October 2015 at 00:39, Stuart Marks <stuart.marks at oracle.com> wrote: >> 1. Number of fixed arg overloads. > > Guava follows this pattern: > > of(T) > of(T, T) > of(T, T, T) > of(T, T, T, T... elements) > > whereas the proposal has > > of(T) > of(T, T) > of(T, T, T) > of(T... elements) > > I'd be interested to know why Guava did it that way and what the trade offs > are. I can't answer for the Guava guys, of course, but I can supply some additional background about why we chose this approach for our proposal.

I remember discussing this kind of things with Kevin Bourrillion something like 5 years ago.

There are several issues with: of(T) of(T...)

if called with null, the overload selected will be of(T...) and the compiler will emit a warning, because it's not clear if of(null) should be called like this of((T[])null) or of(new T[]{null}) (for backward compatibility the former will be used by default).

but even without null, a code like this is ambiguous from the user perspective, String[] array = ... of(array) should it returns a List<String[]> with the array as sole element or a List with all elements contained in the array.

Rémi

More information about the core-libs-dev mailing list