Point lambdaification of List/Set/Map

Mike Duigou mike.duigou at oracle.com
Thu Jul 11 23:04:49 UTC 2013

(Just getting back from vacation)

This seems like a reasonable idea. There has been some concern about adding defaulted non-static methods to these core interfaces because of potential collisions with existing implementations abut that would not seem to be a concern with static methods.

On Jun 26 2013, at 09:47 , Stephen Colebourne wrote:

> Sending this on to core-libs-dev to try to get a response ;-)
> Stephen
> On 24 June 2013 16:14, Stephen Colebourne <scolebourne at joda.org> wrote:
>> One point lambdaification that I haven't seen mentioned is addition
>> static factory methods for the main collection interfaces. (Strictly,
>> this proposal is not point lambdaification as it does not involve
>> lambdas, but it is very much in the same area).
>> I propose adding these static methods:
>> Collection.empty()
>> Collection.of(T...)
>> List.empty()
>> List.of(T...)
>> Set.empty()
>> Set.of(T...)
>> Map.empty()
>> Map.of(Entry...)
>> Map.Entry.of(K, V)
>> Each of these methods would return immutable implementations.
>> There is a case for extending the methods to Iterator and other
>> collection types, however these are the most important.
>> These follow the designs of Stream static methods IIRC.
>> This library change would remove much of the requirement for the
>> "collection literals" change discussed in Project Coin.
>> Implementation would ideally be via new dedicated immutable classes,
>> however space could be saved by simply reusing the existing classes.

I would prefer to use existing Collections implementations. Primarily because they have already been thoroughly used. Any reason to use new dedicated classes?

>> Is this something we could fit in? (Is resourcing the problem, or the idea?)

Patches are *always* welcome and are usually more grease to make things happen than just a squeaky wheel. :-) Without a patch I wouldn't be willing to commit that this RFE would make it into Java 8.


>> thanks
>> Stephen

More information about the core-libs-dev mailing list