JEP 186: Collection Literals

[John Moxley]

I think we need to look at what we are trying to achieve, we seem to be focussing on turning collection literals (these already sort of exist in the form of arrays),  to Collection Objects. What is really being talked about here is the un-primitivisation of arrays, or even dare I say it autoboxing of arrays into collections.

As such I think we should consider non literals in this scope, and even vararg parameters. I strongly suspect the changes would be significantly more applicable to common problems if they did. 

I don’t know whether for varargs you would provide a different form of notation. (Perhaps 2 dots rather than common 3 dot ellipsis, if you declare the collection type)

public void listTastic(String someString, List<Integer> .. someVarArgs);

listTastic(“Hi Mom!”, 1,2,3,4,5);


On 15 Jan 2014, at 06:36, Michael Hixson <michael.hixson at gmail.com> wrote:

> 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
> 
>