JEP 186: Collection Literals
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