JEP 186: Collection Literals

[Mark Derricutt]

On 16 Jan 2014, at 9:24, Remi Forax wrote:

>> I'd also like to avoid binding certain styles to specific interfaces; not
>> all of us use List, Set and Map every day. One notable exception is the
>> pcollections library, which defines persistent equivalents with interfaces
>> such as PVector, PSet, PMap, etc. and is a pretty good example of something
>> that others have hinted they'd like to see in the core Java library. To
>> that end, I'd like for every type to have the option of providing a builder
>> (could we re-use Collector, as Remi hints at?). I know there's the
>> possibility people will abuse this to make Java work like C++ but honestly,
>> I don't think there's much danger. Most people are pretty good at following
>> conventions, even if they're terrible (Java beans spring to mind).
>
>
> I just say that we give up to try to find a common interface for
> injecting values for something more specific to stream.

My NZ$0.02 - I'm somewhat torn on this notion of the builder. Part of me likes it from a flexibility point of view, but a much MUCH larger portion of me would much prefer Java to be both opinionated, and restrained here.

Anything else leads to what you see as one of Scalas biggest sources of API hate - CanBuildFrom[T] on all the collection methods.

IMHO Collection literals should return a) immutable structures or b) persistent structures - of a type that is core/internal to Java.

If they were to be persistent, they can't extend List as add() will need to return a new List - so a new set of interfaces, such a PersistentList which extend the raw Collection types would be needed.

Mark