Hello SonarQube Community,
I am experiencing a strange and inconsistent behavior with some Java rules. The rules only flag a random subset of applicable classes, and I’m having trouble understanding why.
Minimal reproducible example (for java:S1161)
To demonstrate the issue, I have a very simple set of classes. All classes are in the same package.
Base class:
package com.company.app;
public class BaseClass {
public void doSomething() {
System.out.println("Doing something in BaseClass");
}
}
Subclasses:
package com.company.app;
// SubClassOne.java
public class SubClassOne extends BaseClass {
public void doSomething() { // <-- Should be flagged by S1161
System.out.println("Doing something in SubClassOne");
}
}
package com.company.app;
// SubClassTwo.java
public class SubClassTwo extends BaseClass {
public void doSomething() { // <-- Should be flagged by S1161
System.out.println("Doing something in SubClassTwo");
}
}
package com.company.app;
// SubClassThree.java
public class SubClassThree extends BaseClass {
public void doSomething() { // <-- Should be flagged by S1161
System.out.println("Doing something in SubClassThree");
}
}
package com.company.app;
// SubClassFour.java
public class SubClassFour extends BaseClass {
public void doSomething() { // <-- Should be flagged by S1161
System.out.println("Doing something in SubClassFour");
}
}
Observed behavior
I would expect SonarQube to raise a code smell for rule java:S1161 ("@Override" should be used... ) on all four subclasses, since they all override the doSomething() method without using the @Override annotation.
However, the actual behavior is random. On any given scan, SonarQube will report the issue on a different subset of the files.
- Sometimes it reports on
SubClassOneandSubClassThree. - Sometimes it only reports on
SubClassFour. - Sometimes it reports on three of the four classes.
The results are not consistent between scans, even when the code has not changed.
I have also noticed similar inconsistent behavior for other rules. For example, java:S5803 (Class members annotated with "@VisibleForTesting" should not be accessed from production code ). In our codebase, we have several clear violations of this rule, but the scanner only reports the issue in some places, while ignoring other identical violations.
Configuration and environment
- SonarQube Version: Enterprise Edition v2025.1.3
- SonarScanner Version: SonarScanner CLI 7.0.2.4839
- Environment: This issue occurs both when running the scanner on my local machine and in our CI environment.
Crucially, the scanner logs show no warnings or errors. I have run the analysis in debug mode and have confirmed that there are no messages about missing .class files or an incomplete classpath. The scanner appears to be finding all source and binary files correctly.
I have tried everything I can think of to debug this, but the randomness of the issue is what I can’t explain. Has anyone encountered this kind of inconsistent behavior before? Any ideas on what could be causing the Java analyzer to only partially detect these clear violations when the logs appear clean?