JEP 186: Collection Literals

[Zhong Yu]

On Tue, Jan 14, 2014 at 2:44 PM, Ali Ebrahimi
<ali.ebrahimi1781 at gmail.com> wrote:
> May be this JEP include Indexing access syntax for Lists, Sets and Maps?

operator overloading? ...

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