JEP 186: Collection Literals

[Kevin Bourrillion]

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.




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


-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com