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