I do work in nokia, we do a much strict standard for code which analysis by sonar, with the plugin of called sonarLint which can install in IDEA, I can find some bad code smell, an example is in org.springframework.util.FileSystemUtils, we can find below in attachment, I think we should do something for it. and will never introduce any more.
Those are arguably false positives since we do not care about the mkdir() and createNewFile() result there: We only want to make sure they exist, not that we just created them.
Also, our pattern of abstract utility classes without constructor declarations is all over the codebase: Such classes can't get instantiated due to the abstractness, and we ignore the fact that you could create subclasses with public constructors (if somebody has the urge to do, we let it happen).
That said, FileSystemUtils overall is outdated and not used anywhere in the codebase anymore, and now even superseded by NIO in the JDK itself. Let's therefore repurpose this ticket to deprecating FileSystemUtils in Spring Framework 5.0.
We're generally avoiding FileInputStream and FileOutputStream now, as well as file system operations on java.io.File, using the superior NIO.2 API (java.nio.file.Files) instead.
In addition, FileSystemUtils provides variants of deleteRecursively and copyRecursively with Path arguments now since there are no equivalents in the NIO.2 API itself... in contrast to simple copy operations along the lines of FileCopyUtils which do exist in java.nio.file.Files.