Hello!
PS With reuse it becomes more compelling :-) In both cases of
PS singleton/nCopies the spliterator characteristics can be the same
PS and that of the already existing singleton spliterator implementation.
The only difference is the DISTINCT characteristic. I think it's good
to report it
Seems that the patch attachment was filtered out. Just for the case
here it is:
diff --git a/src/java.base/share/classes/java/util/Collections.java
b/src/java.base/share/classes/java/util/Collections.java
--- a/src/java.base/share/classes/java/util/Collections.java
+++
On 30 Jul 2015, at 08:08, Tagir F. Valeev amae...@gmail.com wrote:
Hello!
PS I don’t particular want to add a special spliterator for this
PS case to avoid some profile pollution. Will it not just push the
PS pollution further down the road to Spliterator.forEachRemaining? or to
within
Hello!
PS I don’t particular want to add a special spliterator for this
PS case to avoid some profile pollution. Will it not just push the
PS pollution further down the road to Spliterator.forEachRemaining? or to
within other code?
I just thought that the current idea is to create specialized
Hello!
Current implementation of Collections.nCopies().stream() is as
follows:
http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/share/classes/java/util/Collections.java#l5066
public StreamE stream() {
return IntStream.range(0, n).mapToObj(i - element);
}
@Override
Hi Tagir,
I would agree with you out about changing to use unordered() except that it is
a List that is returned, whose Spliterator is specified to report ORDERED.
I don’t particular want to add a special spliterator for this case to avoid
some profile pollution. Will it not just push the
