JEP 186: Collection Literals

[Brian Goetz]

>     The real question is "how far do we go."  The original Coin proposal
>     stopped at sets, lists, and maps (and had a different syntax for each.)
>        But this seems kind of lame; why can't something that is
>     List-like but
>     not a java.util.List participate?
>
> Is there any real reason to restrict the proposal to implementing any
> specific interface? It seems preferable to able to specify some kind of
> recipe or factory for building an arbitrary concrete type out of a
> collection literal. This could then be associated with the class it
> constructs through a mechanism such as a ClassValue.

That's exactly what I meant by "how far do we go".  The extremes of this 
axis are "set/list/map/array only" at one end and at the other, a fully 
general pluggable mechanism for initialization that could support things 
like Json literals with nested target typing (i.e., a list-like literal 
inside a Json list would be target-typed to a Json list), initialization 
of JavaBean classes using map-like literals, static binding of map-like 
literals to constructors (giving the appearance of named parameters, 
presumably with some concept of symbol), etc.  This feature could be 
very small or very big.

Now, you might ask, why would we choose the simple thing when we could 
choose the grand and abstract?  To re-re-re-state the obvious, modifying 
the language is insanely expensive, and I don't just mean it costs 
Oracle a lot of money.  Every new feature requires every developer to 
learn it so they can read code; it needs to be documented and covered in 
tutorials, books, and training.  It affects tooling (like IDEs).  It 
requires specification, implementation, and conformance testing -- not 
just for us, but for anyone who wants a conformant Java implementation. 
  Each feature interacts, potentially in surprising ways, with each 
other.  Each incremental feature moves us closer to collapsing under the 
weight of complexity.

Just in this course of this thread we've already seen half a dozen grand 
ideas thrown out in the vein of "while you're doing collection literals, 
can you also do..." (e.g., operator overloading), as if it were just a 
matter of decreeing it so, or even as if people think it just hadn't 
occurred to us, and we only needed to be reminded.  And every one of 
these ideas competes with ever other one for attention.

So before jumping on the bandwagon for a given feature, ask yourself: if 
we only got one more feature in Java in the next ten years, is this the 
one you would want?  If not, you probably should be advocating for 
reducing, not expanding, its scope, or for junking it altogether.

Now, some features, like "enhanced integer literals" (i.e., 1_000_000), 
are actually small enough that they can be tossed into the pot without 
pushing much else out.  But such features are few and far between.

For example, how long would you have been willing to delay Lambda to 
make collection literals better?  I suspect (and hope) the answer is 
"none at all".  It almost always is a choice of "this or something else."

> It would be a shame to privilege core library
> classes over third party ones in this regard.

This is a powerful consideration, and another aspect of my "how far" 
question.  The rational thing might actually be to do nothing here. 
Because we may well have a choice of doing something that is assymmetric 
and hacky, but small enough to actually do without upsetting the 
applecart, or something that is symmetric and pleasingly abstract, but 
not remotely as important as the things it might push off the plate.