JEP 186: Collection Literals

[Stephen Colebourne]

On 14 January 2014 17:23, Brian Goetz <brian.goetz at oracle.com> wrote:
> This is a very valid point, and one that has been raised before -- that
> maybe this doesn't need a language feature, that maybe simply some
> library changes would be enough.
>
> In fact, since the goal at this point is to discuss whether we should
> move forward or not with the /exploration/ of the language feature, let
> me restrict the discussion to this point: is this something that needs a
> language feature, or would library support be enough?  Bear in mind that
> the cost of even a simple language feature is probably 100x that of a
> comparable library feature, cost-benefit is an important consideration.

The key to this question is the value of this feature vs other
features. From my perspective, there are certainly many other features
I would consider to be more important. For example, larger changes
such as value types and properties are far more valuable. Smaller
changes such as multi-line strings, null-defaulting operator and
access to maps/lists using array-like syntax are also ahead of this
one.

In terms of usage, I don't find myself missing list-literals that
often (varargs suffice in API design), although I would undoubtedly
use them (in test code) if they existed. By contrast, map literals
would change API design and be much more useful as they would suffice
for named arguments and optional parameters.

Additional factory methods such as List.of(a, b, c) and
ArrayList.of(a, b, c) are valuable irrespective of the progress of the
language change. In my opinion, addition of these methods occur first,
with language support following (possibly both within JDK9)
https://bugs.openjdk.java.net/browse/JDK-8026106

Were collection/map literals to be added I would only support them if
the resulting objects were immutable.

I can see more benefit in this feature if linked to value types such
that a literal is directly/efficiently mapped into memory/bytecode
without the need for vast amounts of bytecode as with current
approaches.

Stephen