JEP 186: Collection Literals

[Remi Forax]

On 01/14/2014 08:38 PM, Kevin Bourrillion wrote:
> As co-author of Guava's immutable collections, which give users the
> convenience of
>
>      static final Map<String, Integer> map = ImmutableMap.of("a", 1, "b", 2,
> "c", 3);
>
> ... I believe these libraries I helped make are not convenient enough.
> Collection literals are a great idea, if the various thorns can be avoided.
>
> I would be tremendously sad if they produced mutable types, making them
> useless for static finals, as well as just generally not what most users
> need.

I agree,
and you can make them constant the same way we make a constant lambda 
constant,
so declaring a static final in that case will be harmful because the 
initialization
of the immutable collections will not be lazy anymore.

Rémi

>
>
>
>
> On Tue, Jan 14, 2014 at 11:29 AM, Jochen Theodorou <blackdrag at gmx.org>wrote:
>
>> If I follow that train of thought, then I see the following (ignore
>> syntax please):
>>
>> HashSet<> set = [1,2,3] //#1
>> LinkedList<> list = [1,2,3,4] //#2
>> MyFavoritStruct struct = [a,b,c] //#3
>>
>> That means, the rhs is only a kind of compile time tuple and gets its
>> real meaning only through the lhs. The compiler could for example
>> transform #1 into: HashSet<Integer> set = new HashSet<Integer>(1,2,3).
>> Meaning the line #1 is valid if there is a fitting constructor (or
>> helper method). And it would be easy for the user to let his structures
>> fit in here (#3). But for example Object o = [1,2,3] is not valid then.
>>
>> I think leveraging the constructor for that has a lot of heated
>> discussion potential. And besides that bigger nested structures will
>> easily become a hurdle. But I wanted to speak out, what seemed to lay on
>> your tongue here in my eyes ;)
>>
>> Though, you may not have meant that, because List<...> l = [1,2,3] would
>> then not be valid, unless you go through a (static) helper method
>> defined in List. And the discussion what exact type l will have will be
>> interesting... started here already actually. And I think there will be
>> no "fits all" type.
>>
>>
>> Am 14.01.2014 18:02, schrieb Brian Goetz:
>>> And, we have now reached our quota of syntax discussion on this topic.
>>> No more, please!  Such discussions get in the way of the important
>>> questions like:
>>>
>>>     - what does this feature *mean*
>>>     - what should the limits of this feature be
>>>     - how does this map to bytecode
>>>
>>>> Problem is that you need to differentiate list and set (and map
>> possibly).
>>> This need not be done syntactically.  We now have precedent and
>>> machinery for using /target typing/ here.  Let's assume the syntactic
>>> problems will be solved when we figure out what this feature ought to be.
>>>
>>> For example, the two lambdas below are syntactically identical, but the
>>> type system knows what they need to be converted to:
>>>
>>>      Function<String, Boolean> f = s -> s != null;
>>>      Predicate<String> g = s -> s != null;
>>>
>>> The same is true for distinguishing linear collections like arrays,
>>> lists, and sets.
>>>
>>> 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?
>>>
>>>
>>> On 1/14/2014 11:19 AM, Paul Benedict wrote:
>>>> I think you could likely achieve all those with curly braces. You'll
>> have
>>>> the help of type inference during assignment (list vs set) plus you can
>>>> nest values whenever you need tuples (maps).
>>>>
>>>>
>>>> On Tue, Jan 14, 2014 at 10:16 AM, Artur Biesiadowski <abies at adres.pl>
>> wrote:
>>>>> Problem is that you need to differentiate list and set (and map
>> possibly).
>>>>> Few examples from existing languages
>>>>>
>>>>> Groovy:
>>>>>
>>>>> List  [1,2,3]
>>>>> Set   [1,2,3] as Set
>>>>> Map   ["a":1, "b":2]
>>>>>
>>>>> Xtend
>>>>>
>>>>> List  #[1,2,3]
>>>>> Set   #{1,2,3}
>>>>> Map   #{"a"->1, "b"->2}
>>>>>
>>>>> Scala
>>>>>
>>>>> List  Array(1,2,3)
>>>>> Set   Set(1,2,3)
>>>>> Map   Map("a"->1, "b"->2)
>>>>>
>>>>> C#
>>>>>
>>>>> List  new List<int> {1,2,3}
>>>>> Set new HashSet<int> {1,2,3}
>>>>> Map   new Dictionary<string,int>  { {"a":1},{"b":2}  }
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>> Artur Biesiadowski
>>>>>
>>>>> On 14/01/2014 16:30, Paul Benedict wrote:
>>>>>> I would like to see Java have one way of doing initialization with a
>>>>> series
>>>>>> of values. C11/C++11 decided that curly braces was the way to go. So I
>>>>>> would agree with Moshe we should favor curly braces over any new
>> syntax.
>>>>>>
>>>>>> On Tue, Jan 14, 2014 at 8:34 AM, Millies, Sebastian <
>>>>>> Sebastian.Millies at softwareag.com> wrote:
>>>>>>
>>>>>>> I would certainly expect it to be an immutable list, and I believe
>> the
>>>>>>> proposal of having collection literals makes most sense in the
>> context
>>>>> of
>>>>>>> persistent collections. This would be in keeping with evolving Java
>>>>> towards
>>>>>>> a more functional and parallel-friendly programming style, which
>> entails
>>>>>>> embracing immutability. In contrast, what's to be gained from a
>> shorter
>>>>>>> version of Arrays.asList() ?  -- Sebastian
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: lambda-dev-bounces at openjdk.java.net [mailto:
>>>>>>> lambda-dev-bounces at openjdk.java.net] On Behalf Of Moshe Sayag
>>>>>>> Sent: Tuesday, January 14, 2014 2:52 PM
>>>>>>> To: lambda-dev at openjdk.java.net
>>>>>>> Subject: Re: JEP 186: Collection Literals
>>>>>>>
>>>>>>> 1. What is the exact meaning of:
>>>>>>>
>>>>>>> List<Integer> list = #[ 1, 2, 3 ];
>>>>>>>
>>>>>>> Will 'list' be an ArrayList, a LinkedList or an immutable list?
>>>>>>>
>>>>>>> 2. Java already has the curly brackets {...} to construct an array.
>>>>>>>
>>>>>>> int[] array = { 1, 2, 3 };
>>>>>>>
>>>>>>> How will the new literal go with it?
>>>>>>> Will we have:
>>>>>>>
>>>>>>> int[] array = #[ 1, 2, 3 ];
>>>>>>>
>>>>>>> What about
>>>>>>>
>>>>>>> List<Integer> list = { 1, 2, 3 };
>>>>>>>
>>>>>>>
>>>>>>> Moshe
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jan 14, 2014 at 2:17 AM, <mark.reinhold at oracle.com> wrote:
>>>>>>>
>>>>>>>> Posted: http://openjdk.java.net/jeps/186
>>>>>>>>
>>>>>>>> - Mark
>>>>>>>>
>>>>>>>>
>>>>>>> Software AG – Sitz/Registered office: Uhlandstraße 12, 64297
>> Darmstadt,
>>>>>>> Germany – Registergericht/Commercial register: Darmstadt HRB 1562 -
>>>>>>> Vorstand/Management Board: Karl-Heinz Streibich
>> (Vorsitzender/Chairman),
>>>>>>> Dr. Wolfram Jost, Arnd Zinnhardt; -
>> Aufsichtsratsvorsitzender/Chairman
>>>>> of
>>>>>>> the Supervisory Board: Dr. Andreas Bereczky -
>> http://www.softwareag.com
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>
>> --
>> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
>> blog: http://blackdragsview.blogspot.com/
>> german groovy discussion newsgroup: de.comp.lang.misc
>> For Groovy programming sources visit http://groovy-lang.org
>>
>>
>>
>