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.ma...@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
