JEP 186: Collection Literals
Michael Hixson
michael.hixson at gmail.com
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.
-Michael
More information about the lambda-dev
mailing list