JEP 186: Collection Literals

Brian Goetz brian.goetz at oracle.com
Tue Jan 21 11:39:23 PST 2014


So, there's been some good discussion regarding the proper scope of 
Collection Literals, so let me summarize what I heard.  I am sensing 
that the center of gravity is roughly behind these points:

1.  A "collection literals" feature that only worked for the built-in 
types (e.g., List, Set, Map), but was not extensible to user-defined 
types, would be disappointing.

2.  Having these literals be mutable would be surprising.

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.

4.  This feature is less critical that many other features, such as 
value types, tuples, or primitive specialization of generics.  For the 
most part, this feature is a nice-to-have, but no one would vote for 
delaying value types because of it.

5.  The underlying mechanics (varargs at the language level; lack of 
constant pool support for arrays at the bytecode level; ad-hoc support 
for caching of (and GC'ing under memory pressure) intermediate immutable 
results) remain a limiting factor, even with syntactic sugar.  Working 
on these foundational issues might provide more bang-for-buck.

Of course, in a community of 10M, there will be some range of opinion, 
but the goal of posting this here was to sanity-check our assumptions 
about priorities.  Thanks to all who provided feedback!


More information about the lambda-dev mailing list