JEP 186: Collection Literals

[Ali Ebrahimi]

May be this JEP include Indexing access syntax for Lists, Sets and Maps?
And what about primitive collections, we have primitive Streams but still
no true primitive collections. (from performance perspective). I just say
avoid boxing and unboxing entirely whatever possible.


On Tue, Jan 14, 2014 at 8:32 PM, Brian Goetz <brian.goetz at oracle.com> wrote:

> There's not a perfect venue, but this is good enough for the current
> purpose: to discuss the /content/ of the JEP.  Actually discussing the
> /language feature/ proposed would come later, once the JEP is approved
> and funded.
>
> This is a /research JEP/, whose goal is to explore the design space and
> come up with a proposal.  But, this JEP is merely in the /Posted/ state,
> meaning it is in circulation for initial review and consensus building
> around the goal, which is to /explore/ the feature.  I'll take the
> vigorous discussion so far as evidence that there is interest in
> exploring the feature, but let's not get ahead of ourselves.
>
> Details on the process here: http://openjdk.java.net/jeps/1
>
> On 1/14/2014 10:49 AM, Paul Benedict wrote:
> > Question to Paul Sandoz: collection literals really have no connection to
> > lambda-dev, right? If that's the case, should all discussion move to
> > coin-dev or another list?
> >
> >
> > On Tue, Jan 14, 2014 at 9:46 AM, Paul Sandoz <paul.sandoz at oracle.com>
> wrote:
> >
> >>
> >> On Jan 14, 2014, at 3:34 PM, "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
> >>>
> >>
> >> Note that Arrays.asList creates a List implementation that cannot be
> >> structurally modified; it cannot grow or shrink and is essentially a
> view
> >> over the array passed (directly or indirectly) to it. That is why one
> sees
> >> annoying code like:
> >>
> >>    new ArrayList<>(Arrays.asList(1, 2, 3, 4));
> >>
> >> or:
> >>
> >>    new ArrayList<Integer>() {{ add(1); add(2); add(3); }};
> >>
> >> --
> >>
> >> One reason why i pause for thought about immutability is List is not a
> >> particularly a good interface for an immutable list of elements.
> >>
> >> Paul.
> >>
> >>
> >>
> >>
> >
> >
>
>