JEP 186: Collection Literals

Stephen Colebourne scolebourne at joda.org
Wed Feb 19 10:02:41 PST 2014


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


More information about the lambda-dev mailing list