JEP 186: Collection Literals

Zhong Yu zhong.j.yu at
Tue Jan 14 12:31:32 PST 2014

I never understood the appeal of literals for array/list/set; it seems
that method+varargs is good enough.

But Map is a different story - a key:value pair cannot be succinctly
expressed by method syntax - `pair(key, value)` contains 3 more
symbols per map entry than the literal syntax `key:value`.

If we could just have a key:value literal, that would be great. There
is no need for Map literal, just do `makeMap(k1:v1, k2:v2...)`

key:value literals will have a lot of applications other than map building.

We may also need heterogeneous key:value pairs with some type
constraints between keys and values, for example

    search("lambda", site:"", max=1000);

which can probably be solved by annotations on site/max constants.

Zhong Yu

On Tue, Jan 14, 2014 at 11:23 AM, Brian Goetz <brian.goetz at> wrote:
> This is a very valid point, and one that has been raised before -- that
> maybe this doesn't need a language feature, that maybe simply some
> library changes would be enough.
> In fact, since the goal at this point is to discuss whether we should
> move forward or not with the /exploration/ of the language feature, let
> me restrict the discussion to this point: is this something that needs a
> language feature, or would library support be enough?  Bear in mind that
> the cost of even a simple language feature is probably 100x that of a
> comparable library feature, cost-benefit is an important consideration.
> On 1/14/2014 12:02 PM, Klaus Malorny wrote:
>> On 14.01.2014 17:33, Nick Williams wrote:
>>   > I think we should also try to keep the Java Unified Expression Language in
>>   > mind while designing this. Java EE 7 added lambda expressions to JUEL. Can
>>   > you imagine how confusing it would have been if they had defined a different
>>   > lambda syntax than Java 8? They didn't, though. They made the syntax mirror
>>   > Java 8 lambdas.
>>   >
>>   > JUEL also has collection literals now, and I think it would be foolish to
>>   > define a literal syntax different than that defined in JUEL. It will make
>>   > developers' lives more difficult. The JUEL syntax is simple and I think it
>>   > would work perfectly in Java as well:
>>   >
>>   > List: [ 1, 2, 3 ] Set: { 1, 2, 3 } Map: { "one" : 1, "two" : 2, "three" : 3
>>   > }
>>   >
>>   > If we, for example, make Lists use curly braces in Java when they already use
>>   > square brackets in JUEL, that would be unfortunate.
>>   >
>>   > Nick
>>   >
>> Hi,
>> if I may add my two cents: I have solved the problem for me by
>> - having a static setOf (...) method to construct sets, which
>>     is imported via static import if need be
>> - having a static mapOf (key, value) method which is the start
>>     of a call chain, ending with map (), which returns the constructed
>>     map,
>>     e.g. Map<String, Integer> map = mapOf ("one", 1).put ("two", 2).
>>            put ("three", 3).map ();
>> Overloaded and alternative methods allow me to create unmodifiable sets and
>> maps, including EnumMaps, also to perform some additional checks for EnumMaps
>> (e.g. whether all keys occur). Similar could be done for lists, of course.
>> So while I do not dislike collection literals, I just want to point out that the
>> keyboard typing benefit isn't that great IMHO.
>> Regards,
>> Klaus

More information about the lambda-dev mailing list