JEP 186: Collection Literals

[Stephen Colebourne]

In the absence of alternatives, Guava's 5 pair overload works well,
but its not ideal. But nor is the unsafe cast version in the patch I
put forward. That said, such an approach would be better than what we
have today for maps in the JDK, which is nothing.

Howard's point on efficiency of varargs is well made. Perhaps a focus
on value types rather than collection literals could also encompass
(as a knock on effect or side project) a better way to pass arrays
into varargs.

Personally, I can't see how a builder can possibly be as neat as
List.of(1, 2, 3).

Stephen



On 20 February 2014 13:45, Brian Goetz <brian.goetz at oracle.com> wrote:
> Also, note that Guava gets away with the cheesy but effective overloads of Map.of:
>
>   Map.of(K, V)
>   Map.of(K, V, K, V)
>   ... for nPairs = 1..5
>
> On Feb 19, 2014, at 10:02 AM, Stephen Colebourne <scolebourne at joda.org> wrote:
>
>> On 21 January 2014 19:39, Brian Goetz <brian.goetz at oracle.com> wrote:
>>> 3.  The real pain is in Maps, not Lists, Sets, or Arrays.  Library-based
>>> solutions would be mostly acceptable for the latter, but we still lack a
>>> reasonable way to describe pair literals, which is what's in the way of
>>> a library-based solution for Map (other than a MapBuilder.)  Static
>>> methods in interfaces make a library-based solution more practical.
>>> With value types, though, library-based solutions for Map become far
>>> more practical too.
>>
>> Just to note on this, I previously sent a proposal to core-libs:
>> http://mail.openjdk.java.net/pipermail/lambda-dev/2013-June/010228.html
>> and a proof of concept patch:
>> https://gist.github.com/jodastephen/6659515
>>
>> The heart of the concept was static methods on interfaces:
>> Collection.empty()
>> Collection.of(T...)
>> List.empty()
>> List.of(T...)
>> Set.empty()
>> Set.of(T...)
>> Map.empty()
>> Map.of(Entry...)
>> Map.Entry.of(K, V)
>>
>>
>> Each of these methods would return immutable implementations. There is
>> a case for extending the methods to Iterator and other collection
>> types, however these are the most important. These follow the designs
>> of Stream static methods IIRC.
>>
>> I think a complete solution would involve matching static methods on
>> the collection classes as well, eg
>> ArrayList.of(T...)
>> TreeSet.of(T...)
>>
>> I note that the Map variant in the patch is a cunning way to beat the
>> absence of a pair/tuple and generics, but it would require some
>> thought before adoption in the JDK.
>>
>> Stephen
>>
>