2

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.

Pablo Fradua
  • 369
  • 1
  • 4
  • 16
  • 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. – Kamil W Oct 26 '18 at 13:09
  • There's no properties file or any configuration in the pom.xml file – Pablo Fradua Oct 26 '18 at 13:15

4 Answers4

6

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.

Tibor Blenessy
  • 4,254
  • 29
  • 35
2

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.

Erwin Smout
  • 18,113
  • 4
  • 33
  • 52
  • 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. – gmanjon Nov 02 '21 at 11:39
  • 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 ? – Erwin Smout Nov 16 '21 at 14:40
  • 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. – gmanjon Nov 16 '21 at 14:59
1

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

Pablo Fradua
  • 369
  • 1
  • 4
  • 16
0

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 .

Kamil W
  • 2,230
  • 2
  • 21
  • 43