by Anton Katilin » Thu Nov 02, 2017 3:21 pm
Hello Thorsten,
Thank you for the suggestion.
It seems that technically this means we should track instances of classes implementing java.nio.file.DirectoryStream (e.g. sun.nio.fs.WindowsDirectoryStream, com.sun.nio.zipfs.ZipDirectoryStream, etc.) for which close() is never called.
We might do this with a new probe keeping a list of created streams and removing from the list those of them for which close() is called. I think you agree that it is not enough if the profiler just tells you that such objects exist, it should also tell where in the code they are created, i.e. to record the stack trace. Because it is yet unknown at the moment of the object creation whether it will be explicitly released with close() in the future, we'll have to record a stack trace for each created stream object. In some cases this might probably add significant overhead.
Anyway, we may try adding such probe. Will you be interested in early testing it?
By the way, I see an alternate approach: while finding such cases in runtime may not be free from the performance point of view, it instead should be just trivial (of course, given all existing capabilities) for an IDE performing static code analysis to immediately find all wrong cases.
Which IDE do you use? IntelliJ IDEA has inspection "AutoCloseable used without 'try'-with-resources"; I just tried it and it doesn't seem to find unwrapped Files.list() in the current version, but we could send the vendor a feature request asking to support them too. I'm not sure about Eclipse but they likely have something similar.
Best regards,
Anton