java:S1874: Working as intended?

[TunaIII (David Sochacki)]

Hi,

lately we ran into a strange issue with rule java:S1874 (“@Deprecated” code should not be used).

The method in use (in our case: java.net.URL(String)) is deprecated in Java 21, but not in Java 17. The variable sonar.java.version is (correctly) set to “17”, since it is a Java 17 project.

If I run the maven scanner by maven (mvn sonar:sonar) on a Java 17 machine, everything is fine in SonarQube. But if I run it on a Java 21 machine, the same SonarQube instance tells me to remove the deprecated rule, even when it is not deprecated in the projects specified java Version.

It seems, the list of deprecated methods in use is based on the java version the sonar scanner is running on, but not on the specified project version.

Is there a way to change this behavior? Am I missing some configuration details?

[ganncamp (G Ann Campbell)]

Hi,

Can you share what version of SonarQube you’re using?

 
Thx,
Ann

[TunaIII (David Sochacki)]

Hi Ann,

we are using SonarQube version 10.8

[ganncamp (G Ann Campbell)]

Hi,

Thanks for that detail. I’ve flagged this for the language experts.

 
Ann

[Colin]

Hey David.

Sorry for the late reply here.

Rules like S1874 rely on knowing the project’s specific JDK, rather than a list of deprecated methods.

@Alexandre_Gigleux

To illustrate this behavior, the following example defines a Java 8 project being analyzed with a JDK 11. In Java 8, the class java.util.Observable is perfectly legit, while in Java 11, the class is deprecated. This situation leads to the rule S1874 (Remove usage of deprecated classes) reporting a False-Positive, while it is OK in the context of the Java 8 project. The analyzer relied on Java 11 classes to resolve the Observable object, while it should have been fed with Java 8 classes.

You can adjust what flavor of Java is “fed” to the scanner by adjusting sonar.java.jdkHome, meanwhile using whatever supported flavor of Java you want to run the scan.