RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

[Stuart Marks]

On 11/24/15 8:06 AM, Paul Benedict wrote:
> *) List.of() says it returns "the newly created list" but it actually returns 
> the same empty list regardless. I don't think you want to imply a new list is 
> actually constructed for each call.
> *) Map.of() same comment as above
> *) Set.of() same comment as above
Right, see previous reply to Chris Hegarty.
> *) Map.of(1/2/3/4/5/6/7/8/9) initializes the map to mystery capacities that 
> aren't explained. Should that be explained in a // comment or {@implNote} ?
It's not part of the spec, so no need for @implNote. But a // comment explaining 
the numbers is probably warranted, since a couple people have asked about this.
> *) Map.ofEntries(Entry<K,V>... entries) no need for check loop var "e" for 
> null since referencing it in the next line will throw NPE if null
I'll clean up.
> *) As the size of the method parameters grow, it becomes more burdensome to 
> know which was the duplicate key in a Map/Set. Is it too expensive to check 
> after each element addition so that can be identified in the exception message 
> (the position at least)?
Good point. Since this isn't the "real" implementation I don't want to spend the 
effort on this at the moment. My prototype compact set/map implementations add 
the elements one at a time and report the first duplicate that they find. I 
fully intend to work on the compact implementation, but on the off chance it 
doesn't get in, the current implementation should be improved to do better 
reporting in this case. I've filed a sub-task JDK-8143974 to track this.

s'marks