List, Set and Map literals

John Hendrikx hjohn at
Thu Oct 8 02:55:36 PDT 2009

I've been following this discussion, and I think that Java should not 
try and conform to what is the "standard" in other languages.  Java is 
its own language with its roots in C style syntax.  If C already has a 
literal syntax that is similar to what is being proposed for Java, then 
by all means use that.  If not, then by all means use a syntax that fits 
well with Java, and C-style languages.  Don't try and re-use syntax from 
other languages that donot even have C style syntax at their roots.

In Java, Arrays and Lists represent the same concept.  If there ever was 
a need for some kind of autoboxing/unboxing it would have been for 
Arrays and Lists.  There is not a day that goes by without having to do 
somekind of Array or List conversion because some functions expect or 
return Lists and others Arrays.  It is with gnashing teeth that I find 
myself adding extra methods in classes for returning both types, or 
accepting both types just to cut down on the boilerplate in caller code.

Of course, I realize the autoboxing/unboxing for Arrays and Lists is a 
non-option.  However, the reason I bring all this up is that to me, 
{"A", "B", "C"} means Array.  And by extension, that means List.

Seeing the square parenthesis syntax proposed for Lists makes me sad.  
It doesn't look like Java, it feels unjava.

C and Java have always had a very clear distinction of the function of 
the various parenthesis styles.

( ) round parenthesis for casts and to customize built-in and 
user-defined functions
[ ] square parenthesis as indexers
{ } curly parenthesis to define groups of related statements or literals
< > angle brackets for generics

The current proposal would blur the lines between the function of square 
and curly parenthesis.

So, the way I see it, staying in the spirit of C and Java syntax, 
there's two good options:

1) Introduce only List and Map literals (both using curly braces), and 
provide static constructors for all other cases.

List<String> a = {"A", "B", "C"};
Set<String> a = HashSet.of({"A", "B", "C"});
Map<Integer, String> a = {1: "A", 2: "B", 3: "C"};

2) Think of another way to differentiate Sets, that does not violate 
basic syntax rules.

Map syntax without keys:

Set<String> a = {:"A", :"B"};

List converted to a set:

Set<String> a = {"A", "B"}.asSet();

A qualifier keyword:

Set<String> a = set {"A", "B"};

A new symbol:

Set<String> a = ${"A", "B"};

Plain old Java:

Set<String> a = new HashSet<>({"A", "B"});


More information about the coin-dev mailing list