garydgregory commented on PR #893:
URL: https://github.com/apache/commons-io/pull/893#issuecomment-6440255282
The issue reported in IO-754 is real, and this PR fixes its example.
However, forwarding `WildcardFileFilter.accept(Path, BasicFileAttributes)` to
the virtual `accept(File)` method introduces another compatibility regression.
An existing subclass can delegate its File implementation to the
superclass’s Path implementation:
```java
final WildcardFileFilter filter = new WildcardFileFilter("*.txt") {
private static final long serialVersionUID = 1L;
@Override
public boolean accept(final File file) {
return super.accept(file.toPath(), null) == FileVisitResult.CONTINUE;
}
};
filter.accept(new File("log.txt"));
```
Before this change, the call returns `true`. With the PR applied, it throws
`StackOverflowError`: the superclass Path implementation calls the subclass
File override, which calls the superclass Path implementation again.
I reproduced this behavior before and after applying the proposed runtime
change. The new tests cover File overrides that delegate to `super.accept(File,
String)`, but do not cover delegation to `super.accept(Path,
BasicFileAttributes)`.
Please add this regression case and reconsider where the compatibility
dispatch belongs. Fixing FileUtils traversal should preserve existing subclass
delegation patterns as well as restore the behavior described in IO-754.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
