This is a little bit tricky problem. Now it's guaranteed that every stream
returned by a function passed into flatMap will be closed. However, if we
avoid buffering for the iterator() method, it would be impossible to
guarantee this as an iterator can be abandoned at any time. E.g. now a
utility method like this is guaranteed to close all the resources no matter
how you use the Stream:
Stream<String> allLines(List<Path> paths) {
return paths.stream().flatMap(p -> {try{return Files.lines(p);}
catch(IOException ex) {return null;}});
}
However, if short-circuiting behavior for an iterator() is implemented, and
iterator() is abandoned in the middle of an iteration, then you may end up
having a resource leak.
With best regards,
Tagir Valeev.
On Thu, Aug 22, 2019 at 1:45 AM Roger Riggs <roger.ri...@oracle.com> wrote:
> Created an issue to track this:
>
> JDK-8229983 <https://bugs.openjdk.java.net/browse/JDK-8229983> flatMap
> still prevents short circuiting when using .iterator()
>
> Regards, Roger
>
> On 8/20/19 4:55 AM, Stephen Buergler wrote:
> > Oops thanks.
> > So I think the issue is that StreamSpliterators.java has this line
> > bufferSink = ph.wrapSink(b::accept);
> > that creates a Sink that never returns true in cancellationRequested()
> > which is needed to get flatMap() to stop looping.
> >
> > On Thu, Aug 15, 2019 at 7:43 PM David Holmes <david.hol...@oracle.com>
> wrote:
> >> Re-directing to core-libs-dev
> >>
> >> David
> >>
> >> On 15/08/2019 7:48 pm, Stephen Buergler wrote:
> >>> Not really sure where to send this.
> >>> flatMap was fixed so that it doesn't prevent short circuiting.
> >>> https://bugs.openjdk.java.net/browse/JDK-8075939
> >>> If you replace the test cases in the ticket with versions that use
> >>> .iterator().next() instead of .findFirst().get() then the problem
> >>> still happens.
> >>> I just tested this with openjdk:14 on docker hub.
> >>>
>
>
