Could we add a utility to delete the content of a whole directory?

[gsmet]

I'm trying to get rid of our usage of Commons IO in Quarkus. For most of the use cases, I can just use java.nio instead but there are a few uses cases for which it would be nice to have some proper util in SmallRye Common.

A few of them I could spot in our code base, not saying all of them should be added but we know they are used:

• org.apache.common.io.FileUtils.deleteDirectory: delete an entire directory
• org.apache.common.io.FileUtils.cleanDirectory: clean the content of a directory: this one
• org.apache.common.io.FileUtils.deleteQuietly: delete whatever is there (file or entire directory) quietly, no exception if it fails
• org.apache.common.io.FileUtils.copyFileToDirectory: will copy a file to a directory, preserving the timestamp and creating the directory structure if needed
• org.apache.common.io.FileUtils.moveDirectory: move or copy/delete a directory when not on same fs One is the ability to delete an entire directory:
• org.codehaus.plexus.util.FileUtils.copyDirectoryStructure: we are using it once in test code

I will update the list while I investigate this.

Ideally if we could start a class with some common utilities that are missing from the JDK, that would be cool.

[gastaldi]

I've prototyped an API with these methods in https://github.com/gastaldi/smallrye-common/blob/files/io/src/main/java/io/smallrye/common/io/Files.java

[gsmet]

@gastaldi I wonder about the name. Because I'm pretty sure we don't want it to clash with java.nio.file.Files.

I don't see a lot of options apart adding a suffix but it's not ideal given prior SmallRye Common naming.

[gastaldi]

@gastaldi I wonder about the name. Because I'm pretty sure we don't want it to clash with java.nio.file.Files.

I don't see a lot of options apart adding a suffix but it's not ideal given prior SmallRye Common naming.

Yeah, same here. I followed the pattern we used in other classes (eg. JarFiles). I don't have a strong preference TBH, open for suggestions

[dmlloyd]

We should stick with working with Path rather than File (though we could have convenience wrappers which accept File and convert them to Path). Recursive directory processing should prefer SecureDirectoryStream where available to minimize errors. I think there are some examples in the Quarkus codebase.

We don't have to overthink the name; it can be FileUtils or Files2 or MoreFiles or FrolickingWithButterflies or whatever. Avoiding name conflicts is probably the most important thing.

[Ladicek]

Note that this is not as easy to implement as it sounds, see https://guava.dev/releases/21.0/api/docs/com/google/common/io/MoreFiles.html#deleteRecursively-java.nio.file.Path-com.google.common.io.RecursiveDeleteOption...- for the Guava javadoc and especially the warning. I agree we shouldn't add a dependency on Guava, but we should very much learn from their experience.

[dmlloyd]

To make matters worse, SecureDirectoryStream was not available on Mac until Java 24 AFAIK.

[dmlloyd]

Interestingly, as of Java 26 (maybe), more operations are being added to SecureDirectoryStream: https://github.com/openjdk/jdk/pull/26950