JEP 186: Collection Literals

[Brian Goetz]

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
>