JEP 186: Collection Literals

[Patrick Wright]

>
> 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.
>
> I do like the idea of having collection literals in Java.

One point in favor of that is that in the last couple of years other teams
have added them even when starting from a blank slate - Dart, for example.

One point against them is that the type of the collection is most likely
fixed forever once the language has been updated. Once you decide what
implementation class to use for a list literal, how could you ever change
it, from, say, mutable to immutable, or to a persistent version? It seems
to me that #[1,2,3] becomes short hand for, say, a new java.util.ArrayList.
The type will become visible during reflection and people will come to
depend on that implementation detail. I'm not sure how you could modify the
implementation being used without risking breaking existing code. That part
of it seems unfortunate, as in the current situation we, the programmers,
always make the choice of what implementation we want to use.

An analogy might be a character buffer literal. At some point, the
recommended practice was to stop using StringBuffer and to use
StringBuilder instead. But developers then had a choice about when to
expend the effort and take on the risk in changing their code. If we had a
literal char buffer class, could you change the implementation like that
between two major releases and be confident you wouldn't break something in
production?

To put it another way - it's an implicit understanding that in Java
implementation classes are specified via imports somewhere in some part of
our code, in a library or in the JDK, not by the compiler.