Inconsistenct rules reporting when Sonar project is connected

SonarQube Server / Community Build
1

Server is running: Developer Edition v2026.4.1 (126914) deployed via Helm without additional extensions.

We have several Java rules that are detected correctly both in the CI maven runs AND local Eclipse plugins (e.g. S2259) when no project is associated, but are not reported, when a quality profile is associated to the project.

We double checked that the rules in question are activated in the profile and thus should be reported with the active profile / project association as well.

Eclipse Plugin reports a possible NPE (S2259) in this example correctly in both occurrences, when no Sonar project is associated:

grafik
grafik816×438 58.6 KB

When a Sonar project is associated to the Eclipse project the behaviour gets weird. The project itself has no special configuration at all, only the association to a quality profile that inherits the “Sonar way” default Java profile. The behaviour is exactly the same, when the “Sonar way” quality profile is associated to the project directly. The same result is observable in the CI run using the maven plugin.

As can be seen in this example, the detection S2259 is inconsistent, based on unrelated code AFTER the violation. First observable discrepancy is the different error description.

Here the violation is not reported in the first method (getFile()) but in the second on (run()) as opposed to being correctly reported in both above:

grafik
grafik565×403 48.4 KB

Simply removing the useless code AFTER the possible NPE results in the rule being reported:

grafik
grafik518×297 40.9 KB

This leads to false negatives in our analysis where occurrences are simply not reported at all despite them being found by the Eclipse plugin without project association.

Rule S2259 is only ONE example, this applies for a couple of other rules in the same way, where they are reported in some places, but not in others.

Any idea what could provoke such inconsistent behaviour?
We’d be happy, if we could get a reliable and consistent report of findings in our CI runs and Eclipse dev environments!

Cheers

2

Hey @guidow!

When using SonarQube for Eclipse in standalone mode (meaning, not connected to your SonarQube instance), a legacy implementation of S2259 is used. This is why in the pop-up, the rule’s ID is java:S2259. This is the full name of the legacy version of the rule.

However, when connecting the IDE extension to a commercial SonarQube version (in your case, Developer Edition), the modern implementation of the rule is downloaded from the server and used instead. This would be javabugs:S2259, you can also see this in your pop-up. We call these “DBD rules”.

DBD rules take into account the execution flow and reachability of the code. If the DBD rule doesn’t flag the line in your getFile() method, it’s probably because it’s never executed, and hence, it could be argued that it’s not a real issue.

I suggest you have a look at the “DBD rules” section of our SonarQube for Eclipse docs. It outlines what I explained here and points to a few resources for further reading, in case you’re interested!

3

Hi @andres !

Thanks a lot for your reply. This explains at least the different behaviour.

But the flow analysis of the modern implementation seems to be broken. The line that is missed by it is the first line of the method, which would be executed regardless of the code behind it. Simply adding useless code behind it should not impact the analysis of it.

We havent seen such issues in earlier versions of the Developer Edition (We’re using it for years now…), so it might be something new. And as this no only affects S2259 but many others (we have identified ~30 by now), this really impacts our dev cycle…

We have not changed the config of any of the rules.

Best regards,
Guido

4

If the method was unused, or only called from some other unused code, that would explain the issue not being raised on that line, on account of that line being unreachable. Is it not the case? If you believe it’s not the case, then I would ask you if you could share a minimal reproducer, a small project or file that isolates this false negative. Of course, before sharing it, please check yourself that indeed the rule is not being raised!

5

Hi @andres

In our example above both methods are used as can be seen by the first instance of the call being correctly identified as possible NPE.
The weird thing is only that completely unrelated code that exists AFTER the method call in question seems to confuse the data flow detection.

I think the example should be enough to see the issue but we can put together a complete, isolated mini project, if required.

6

Hey @guidow, yes please, I need you to share a self-contained example, as in the screenshots you shared I cannot verify that getFile() is reachable and therefore that there’s an execution path that would throw the NPE.

7

Hey @andres

Sure!
Here you go:

package sample;

public class Sample {

private void someMethodRequiresNonNullParameter(Object object) {
    object.toString();
}

public byte[] getData() {
    someMethodRequiresNonNullParameter(null);

    try {
        return new byte[0];
    } catch (Exception e) {
        // noop
    }

    return new byte[0];
}

public byte[] getData2() {
    someMethodRequiresNonNullParameter(null);

    return new byte[0];
}

}

This is the correct marking of both instances when no project is connected:

grafik
grafik699×487 18.2 KB

In this screenshot you can see the marking missing in line 10, when a project is connected:

grafik
grafik537×468 15.9 KB

Cheers,
Guido

8

Hey @guidow, thanks for confirming, I will pass this on to the developers!

10

Thanks a lot! Looking forward to their analysis.