RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

[Peter Levart]

Hi Patrick,

On 11/10/2017 09:49 AM, Patrick Reinhart wrote:
> Hi Stuart,
>
> After having thought over your arguments about copyOf versus unmodifiableCopyOf length discussion (also with my colleague) I was thinking about why not create additional X.of(X) methods instead of X.copyOf(X). It would seem to me a logical enhancement in the sense of the existing API though.
>
> -Patrick

I'm sure Stuart thought of that, but decided against it because of usual 
ambiguity problems that occur when two candidate .of() methods apply at 
the same time, for example:

List<String> strings = List.of("a", "b", "c");

List<?> foo = List.of(strings);

What did programmer want to end up in foo, List<List<String>> or 
List<String>? What did javac choose? Answers may differ.

Regards, Peter

>
>> Am 02.11.2017 um 23:04 schrieb Stuart Marks <stuart.marks at oracle.com>:
>>
>>
>>> Why not using:
>>>
>>>      coll.stream().collect(Collectors.toImmutableSet())
>>>
>>> As Collectors.toImmutableSet() is currently implemented, with serial Stream it will create a single HashSet, add all the elements to it and call Set.of(HashSet.toArray()) with it. Pretty much the same as what Tagir proposes, but the Collector could be made more efficient in the future and with it, the optimization would automatically extend to Set.copyOf()...
>> This is mainly about whether Set.copyOf() is implemented in terms of Collectors.toUnmodifiableSet(), or vice-versa, which then calls Set.of(T[]) to do the actual creation. Some future optimization will probably replace both of these implementations with calls to JDK internal methods that can bypass the extra copying, so it doesn't really matter which one of these calls the other right now.
>>
>> s'marks
>>