Please add your comments and proposals for the problems listed below.
Suggested form of voting for existing proposals :
Problems to be addressed :
Exception on close
Operation "close" for any Closeable object may fail with IOException. IOUtils from Apache commons-io offers method closeQuietly which is often used in Sonar ecosystem, whereas this method completely ignores fact of failure, which means that leak of resources completely hidden and non-detectable. This is especially important when closing resources of Zip entries, because closing of ZipFile doesn't guarantee that all resources were freed.
Evgeny Mandrikov : Start using helper methods from Google Guava (requires Sonar >= 2.13) :
"Warning" log level should be enabled by default in Sonar for "com.google.common.io.Closeables" :
Fabrice Bellingard : +1
Evgeny Mandrikov : another solution proposed in http://illegalargumentexception.blogspot.com/2008/10/java-how-not-to-make-mess-of-stream.html - close resources twice ( within try and within finally ) :
Dinesh Bolkensteyn In one case I guess that the IOException is wrapped in a RuntimeException in one case (closeSilently), however in the other it is not (stream.close). Therefore to be equivalent to Guava's solution, an additional catch IOException with Throwables.propagate is required, making it more complex than Guava. I don't think that this is a critical problem, nor even a major one, we have plenty of time to fix it, so it does probably not hurt to wait until Sonar 2.13 in order to be able to make use of Guava, in the case of plugins. That being said, in the (very) long term, Java 7's try-with-resources should be used instead IMO.
Simon Brandhof I agree that we should not abuse of IOUtils#closeQuietly() when notification on failure is valuable. Ok for using the two first suggested patterns. Do you know how Guava logs warnings ? With JUL ?