[ 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)