JEP 186: Collection Literals

Howard Lovatt howard.lovatt at gmail.com
Tue Jan 21 12:46:16 PST 2014


Nice summary that has succinctly captured the spirit of the discussion. 

Sent from my iPad

> On 22 Jan 2014, at 6:39 am, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> 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