[
https://issues.apache.org/jira/browse/IO-811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Rauch reopened IO-811:
---------------------------
FileUtils.listFiles() is now correctly closing the stream. Thanks!
FileUtils.iterateFiles(), however, does not close the stream after the iterator
is consumed. I believe the issue is that StreamIterator.iterator() does not
return a StreamIterator wrapper... instead it returns the supplied stream's
iterator:
{code:java}
public static <T> Iterator<T> iterator(final Stream<T> stream) {
return new StreamIterator<>(stream).iterator;
}{code}
Therefore the wrapper's methods are never called.
Simple test code:
{code:java}
try (Stream<Integer> stream = Stream.of(1, 2, 3).onClose(() ->
System.out.println("Closing!"))) {
System.out.println(stream.map(String::valueOf).collect(Collectors.joining("\n")));
}
Iterator<Integer> iter = StreamIterator.iterator(Stream.of(1, 2, 3).onClose(()
-> System.out.println("Closing!")));
while (iter.hasNext()) {
System.out.println(iter.next());
}
{code}
Note that I couldn't test StreamIterator directly because the class isn't
public... is there a reason why the factory method is public but the class
itself is not?
> Files.walk() direct and indirect callers fail to close the returned
> Stream<Path>
> --------------------------------------------------------------------------------
>
> Key: IO-811
> URL: https://issues.apache.org/jira/browse/IO-811
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
> Affects Versions: 2.13.0
> Environment: Windows 11, Eclipse Adoptium OpenJDK 17.0.8.1+1
> Reporter: Adam Rauch
> Priority: Major
> Fix For: 2.14.1
>
>
> JDK method Files.walk() clearly documents that the returned Stream<Path> must
> be closed: "This method must be used within a try-with-resources statement or
> similar control structure to ensure that the stream's open directories are
> closed promptly after the stream's operations have completed." However, the
> Commons IO methods that consume these streams fail to close them. And the
> methods that pass on these streams fail to document that closing them is
> required.
> Problematic methods that I see:
> * PathUtils.walk() lacks a documentation warning
> * FilesUncheck.walk() both variants lack a documentation warning
> * FileUtils.streamFiles() lacks a documentation warning
> * FileUtils.listFiles() consumes a Files.walk() stream without closing it
> * FileUtils.iterateFiles() claims to close the stream if the iterator is
> consumed, however, in my test of consuming an iterator returned from this
> method, a breakpoint set on FileTreeWalker.close() is never hit
> Failing to close these streams can result in file handle leaks and other
> problems, hence the importance of documenting and heading this requirement
> from the JDK method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)