java on sonarqube server: OpenJDK Runtime Environment (build 11.0.7+10-post-Debian-3deb10u1
java on scanner: OpenJDK Runtime Environment (build 1.8.0_252-8u252-b09-1~16.04-b09)
minimal code sample to reproduce:
//this triggers squid:S2095
new FileReader("/etc/hostname");
//this should trigger squid:S2095 too, but does not
org.apache.commons.io.IOUtils.readLines(new FileReader("/etc/hostname"));
For whatever reason sonarqube ignores unclosed Reader when the reader is passed to method org.apache.commons.io.IOUtils.readLines(....
When the same reader is opened and unclosed without calling the readLines method, it is reported correctly as S2095
Thanks for the feedback and the reproducer. For your information, what you are reporting is a False Negative (FN), and not a False Positive (FP): we miss an actual true issue. A False-Positive being that we wrongly report an issue where there is none.
However, on this case, this is a known limitation of our current Symbolic Execution engine on which the rule S2095 is built. We are well aware of the limitation and, while we try to mitigate such case as possible, this one is actually not easy. What we face here is the following question: How to statically know which method will close or not a resource passed as argument?
Based on our investigations, following each and every method invocation into bytecode has been proven both costly and error-prone, leading to large amounts of FPs. Listing methods NOT closing issues is an endless task, as listing methods actually closing them.
In order to reduce the noise, our current implementation consequently assume that every method invocation having a resource provided as argument will close it. It’s an approximation who leads to FN, like in your case, but it prevent to have to deal with tons of FPs.
For the time being, we don’t have any fix or workaround yet planned.