JEP 186: Collection Literals

[Nick Williams]

I would argue strongly in favor of a language feature as opposed to /only/ library changes. IMO, the following second line is extremely favorable over the first line:

List<List<String>> list = Lists.immutableOf(Lists.immutableOf("hello", "world"), Lists.immutableOf("foo, "bar"), Lists.immutableOf("baz", "qux"));

List<List<String>> list = [ [ "hello", "world" ], [ "foo", "bar" ], [ "baz", "qux" ] ];

That's a far less verbose—and thus more readable—choice. Plus, how would "map literals" work with a library-only change? Un-generified, alternating parameters to a method?

@Suppress("unchecked")
Map<String, Map<String, Integer>> map = Maps.immutableOf("app1", Maps.immutableOf("one", 1), "app2", Maps.immutableOf("two", 2), "app3", Maps.immutableOf("three", 3, "four", 4, "five", 5));

Yuck! This is much better:

Map<String, Map<String, Integer>> map = { "app1" : { "one" : 1 }, "app2" : { "two" : 2 }, "app3" : { "three" : 3, "four" : 4, "five": 5 } };

I think the need for collection literals as a language feature becomes clear here.

Nick

On Jan 14, 2014, at 11:23 AM, Brian Goetz 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
>> 
>