Does java:S5738 affect old Java?

In SonarLint 10.2.1 we are getting dinged for java:S5738 because we are using constructors for boxed types like Integer. The code, however, is compiled for Java 8. When scanned with Maven and Maven’s source set to 8, the rule is never triggered. In a different project compiled for 17, we see the rule being triggered.

So is SonarLint supposed to be aware of the code version and not apply the rule when compiling for 8? In IntelliJ IDEA I tried adding this property


and rescanning the file but the issues are still there.

Hey there!

Can you try setting sonar.java.jdkHome as documented here?

No luck. I set my properties in SonarLint (in IntelliJ) as follows:

Then I hit “Analyze current file” – the green “play” icon:
ScreenshotSLsetJava8c

And the refresh looks the same as before. I also tried the path without the bin, no difference.

Note that the lines at the top, for the deprecated method issues, don’t have the blue sonar icon like the ones below. I assume the ones WITH that icon are the ones SL downloaded from the SQ server, whereas the ones without that icon are being detected by SL independent of what is on the server. These issues are NOT on the server. What is on the server is the result of running the SQ scanner on Maven, where the Java version is set to 1.8 and we didn’t set jdkHome. (In a separate project where the JDK version is 17, the SQ scan on Maven does pick up uses of deprecated calls.)

Hello @MisterPi,

SonarLint should automatically infer the JDK to use from the project configuration, no need for extra configuration. You can double-check by right-clicking on your project then Open Module Settings > Project Settings > Project > SDK, where a JDK 8 should be set. If it’s a Maven project, I think IntelliJ should automatically populate this field.

I just tried on my box by applying a JDK 8 as described and java:S5738 is not triggered.

Please be aware that even if in your case this rule shouldn’t raise issues because the constructor is not yet marked as “scheduled for removal” in Java 8, the point is still valid: you should prefer using valueOf instead of constructors for wrapper types. This is normally highlighted by java:S2129