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