For further consideration, round 2

[Greg Brown]

Hi all,

I just came across this thread and wanted to comment:

http://mail.openjdk.java.net/pipermail/coin-dev/2009-June/001945.html

Hope I'm not too late.

> 6,7 (Elvis and Other Null-Safe Operators,  Indexing access syntax for
> Lists and Maps)

> 8,9, Strings in switch, Collection Literals.


IMO, the Elvis operator would be handy, though definitely not a must  
have. Same goes for Strings in switch statements. My main interest is  
in the other two items: "Indexing access syntax for Lists and Maps"  
and "Collection Literals".

1) Indexing access syntax for Lists and Maps

It would be nice to see this feature extended to any class, not just  
List and Map. Groovy supports this by mapping the index operator to  
getAt() and putAt() - a similar approach (possibly one that maps to  
get(int)/set(int, E) and get(K)/put(K, V)) would be more flexible and  
would still work for List and Map.

2) Collection Literals

I would argue that, since List, Map, and Set are not part of  
java.lang, they should not be given special language-level treatment.  
Also, I don't like the ambiguity of what type of collection is  
actually created. Finally, I'm not sure I see a strong enough use case  
here to justify a language change.

Why not just add some new varargs methods to meet this need? List and  
Set would be easy:

List<Integer> list = ArrayList.unmodifiableList(1, 2, 3);
Set<String> set = HashSet.unmodifiableSet("a", "b", "c");

The resulting code is fairly concise, doesn't require any language  
changes, and eliminates any ambiguity about what type of collection is  
created. Map would require a bit more effort since there is currently  
no class to represent a key/value pair, but could work something like  
this:

Map<String, Integer> map = HashMap.unmodifiableMap(new  
Map.Pair<String, Integer >("foo", 123),
         new Map.Pair<String, Integer >("bar", 456));

A language extension for pairs might make sense, if Pair was defined  
in java.lang and the rules for type inference could be extended to  
support it:

Map<String, Integer> map = HashMap.unmodifiableMap({"foo":123}, {"bar": 
456});

But again, is there really a strong enough use case for collection  
literals in Java to justify any kind of language change? If you are  
finding that you truly need collection literals, is it possible that  
Java just isn't the right language for the problem you are trying to  
solve?

-Greg