For further consideration, round 2

[Greg Brown]

> If "It's not in java.lang" is a valid argument, then we should get  
> rid of the magic that makes java.io.Serializable work, as well as  
> the foreach loops, which use java.lang.Iterable, which refers to  
> java.util.Iterator, which is just not allowed in a java language  
> feature, apparently.

IMO, Iterator belongs in java.lang. But it lives in java.util because  
it predates Iterable and for..each. And I'm not a big fan of "magic"  
in any capacity - Serializable is no exception. I don't like  
Serializable's special status. I don't particularly like String's  
special ability to use the "+" operator, either, but that's another  
story.

> OR, we stop worrying about package names and treat proposals based  
> on their merits, instead of pointing out irrelevant distractions

Even if we take that argument off the table, there's still the  
question of the type ambiguity and the viability of the use case, both  
of which question the proposal's overall merit.

>> Map<String, Integer> map = HashMap.unmodifiableMap(new
>> Map.Pair<String, Integer >("foo", 123),
>>         new Map.Pair<String, Integer >("bar", 456));
>
> Just look at it. And then look at this:
>
> 	Map<String, Integer> map = {"foo": 123, "bar": 456};
>
> Now choose which one you'd rather look at, let alone type.

Sure, it's more readable. But it doesn't matter what you or I think is  
"prettier". It's a question of design. If such syntax can be achieved  
along with a good design, then I'm all for it. Otherwise, not so much.

>> A language extension for pairs might make sense
>
> ... but list and map literals don't. Okay. Why?

As I said, I think language-related classes belong in java.lang. So,  
if Pair is added to java.lang, there's a stronger argument for  
extending the syntax of the language to use it.

> How would pairs type? A new 'java.util.Pair' type, or should it be  
> in java.lang, which means any existing class named Pair (and, boy,  
> are there many of those!) are now in a namespace conflict, causing  
> fun times for everyone that imports their own Pair class via a star  
> import?

Fair enough. But that doesn't make the design wrong - it's just a  
practical challenge.

>> But again, is there really a strong enough use case for collection
>> literals in Java to justify any kind of language change?
>
>
> Yes, there is. Do a code check on how many collection literals you  
> make versus how often you do a list member lookup by index. In my  
> code I'm looking at roughly a 50:1 ratio.

Again, fair enough. I don't have such a strong use case, but perhaps  
others do.