JEP 186: Collection Literals

Michael Hixson michael.hixson at
Tue Jan 14 22:36:07 PST 2014

To focus on one part of one proposal:

  List<String> list = #[ "a", "b", "c" ]; // immutable
  Set<String> set = #{ "a", "b", "c" }; // immutable

The value of that appears extremely small to me given the existence of
varargs and library-based solutions.  If that sugar were added to
Java, I might use the Guava collections instead because:
 - They advertise immutability in the type.
 - They provide builders.
 - They reject nulls.  I'm assuming the JDK implementation would accept nulls.

If the collection literals produced mutable ArrayList and HashSet,
then I am gaining very little over Lists.newArrayList(...) and
Sets.newHashSet(...).  I hardly use those methods in the first place.

Library-based solutions for maps are less good.  But they aren't
*that* bad, and there are other language features that could help
improve the situation (tuples, interleaved varargs).  I'm not sure I
value a HashMap or immutable Map literal more than those features, and
in turn I value those features less than other ones mentioned in this
thread (named parameters, primitive generic types, value types).

Basically, I think a proposal that's tied to particular JDK-provided
collections is not worth pursuing.  The proposal would have to be on
the exotic end of the spectrum that Brian mentioned.  So far I haven't
seen one that looks worth the cost of learning (and teaching) the new
syntax, even if its implementation appeared instantly/magically
without delaying other development.


More information about the lambda-dev mailing list