Sonarqube false positive for "Use try-with-resources or close this "ResultSet" in a "finally" clause"

Question

Sonarqube keeps marking code with this issue which is, in my opinion, a false positive. Code looks like this:

try(PreparedStatement st=con.prepareStatement(myQuery)){
    st.setInt(1, myValue);
    ...
    ResultSet rs = st.executeQuery();
    ...
}

If I'm not mistaken, the PreparedStatement implements Closeable and, when closing itself, it also closes the underlying ResultSet.

This behaviour would prevent the ResultSet from being kept open, yet Sonarqube analysis marks it as a critical error.

Am I mistaken? Any way of making Sonarqube ignore this rule under this circumstances?

Tested under Sonarqube 6.7.3 and JDK 8.

From the ResultSet javadoc:

A ResultSet object is automatically closed when the Statement object that generated it is closed, re-executed, or used to retrieve the next result from a sequence of multiple results.

Shammer

Provide your sonar configuration properties (sonar-project.properties file or properties from pom if you're using maven-plugin) maybe in that place could be something wrong. – Baroness

There's no properties file or any configuration in the pom.xml file – Shammer

Answer 1

This was finally fixed by the Sonarqube team, starting with the 6.7 release.

Shammer

Answer 2

Indeed this is a false positive. It was already reported and there is open ticket to fix it https://jira.sonarsource.com/browse/SONARJAVA-2060

You can mark the issue as false positive in SonarQube UI, or add // NOSONAR comment on the line where the issue is raised to ignore it.

Endres

Answer 3

It's probably unreasonable to expect code analyzers to know such things. Can a tool know all the -additional- semantics of all Closeables in all libraries written anywhere anytime ?

The doco indeed mentions that "the current ResultSet, if any, is also closed".

Note "the current". What happens if you happen to have two distinct executeQuery() invocations ? Will it fail on bad status or some such ? Will there be two distinct ResultSet objects, both unclosed and one of them now unreferenced ?

(Note : two distinct executeQuery() invocations might sound like completely insane, but remember "coders can do anything" and that is even the very reason why tools such as SonarQube are written in the first place.)

I'm not saying it's entirely undebatable, but to me it doesn't seem that strange if the analysis tool just sees you getting a Closeable and not closing it and just simply complain about it.

Gilbreath

The second "executeQuery" will close the previous result set too, according to the same documentation (if the statement is re-executed). The ResultSet being close after the Statement closing is specification, and as such every anylizer (and developer) must develop according to it. As @tibor-blenessy mentioned, there was a sonarqube bugfix about that. – Marcasite

Then this point remains : if it's not PreparedStatement and ResultSet, but Foo and Bar instead (from any random library/package X), then how will the analyzer know that the same property that holds between PreparedStatement and ResultSet (i.e. that closing one is "tied together" with closing the other - and note carefully, only in one particular direction) will also hold between Foo and Bar ? – Gilbreath

I understand your point, but I think is not the same. Library X is not part of the standard language that the sonar rules have been created for. – Marcasite

Answer 4

There's no properties file or any configuration in the pom.xml file

Please take a look at this documentation, you can create sonar-project.properties file in your root project directory set a lot of diffrent properties which have impact on your analysis. One of them is sonar.java.source which allow you specific concreate java version. (details)

Any way of making Sonarqube ignore this rule under this circumstances?

I had situation when sonarqube engine mark block of code as an issue, but from developer point of view it wasn't, so in that case it's candidate to mark it as false-positive. To set rules which allow/disallow marking issues on specific files, please refer this sonarqube documentation .

Baroness

Will try setting the sonar.java.source. The false positive way isn't an option due to the huge number of ocurrences. – Shammer

Even if it's sonarqube issue you can narrow focus as I mentioned above. – Baroness

There is no such property as far as I know. Where did you find it? I don't think it's going to help with OP problem. – Endres

@TiborBlenessy docs.sonarqube.org/display/PLUG/Handling+Java+Source+Version – Baroness

@KamilW. sorry, you were right, I forgot about this one. However this is not going to change anything about this rule, as it is not Java version specific – Endres