Findbugs is reporting false positive bugs SA_LOCAL_SELF_COMPARISON when using instanceof pattern matching
mpet opened this issue · 13 comments
Issue Description
When running sonar rules on java code that has the following construct:
Sonarqube rule: findbugs:SA_LOCAL_SELF_COMPARISON
gives a false positive.
Environment
Component | Version |
---|---|
SonarQube | Community EditionVersion 9.9 (build 65466) |
Sonar-FindBugs | FindBugs 4.2.3 / SpotBugs 4.7.3 |
Maven | 3.8.5 |
Gradle | |
Java | 17 |
Code (If needed)
private static X509Certificate readCertificatePEMFile(String certificatePemFilePath)
throws IOException, CertificateException {
if (certificatePemFilePath != null) {
File certificatePemFile = getCertificatePEMFile(certificatePemFilePath);
if (certificatePemFile.exists() && certificatePemFile.canRead()) {
try (InputStream inStream = new FileInputStream(certificatePemFile)) {
try (PEMParser pemParser = new PEMParser(new InputStreamReader(inStream))) {
Object object = pemParser.readObject();
if (object instanceof X509CertificateHolder x509CertificateHolder) {
return new JcaX509CertificateConverter().getCertificate(x509CertificateHolder);
}
}
}
}
}
throw new MsranJcatException(String.format("error CA trust certificate pem file!%n{}", certificatePemFilePath));
}
This is the same issue as spotbugs/spotbugs#1992 most probably
My understanding (based on spotbugs/spotbugs#1435 (comment) and spotbugs/spotbugs#1992) is that the issue was actually caused by compilers (ecj, javac) producing some redudant bytecode.
Maybe while testing with the gradle plugin you also changed the compiler?
It is not clear to me what was fixed (nor where or when). From what I can see only a unit test reproducing the issue was added to the SpotBugs project, but I might have missed something
I am a bit confused now since when I run with the spotbugs maven plugin,spotbugs-maven-plugin, on the below code:
https://github.com/manikmagar/java14-examples/tree/master
Both spotbugs versions 4.7.3.0 and 4.8.2.0
But I get a different bug reported?!
I think you need to share a way of reproducing the problem or we won't be able to help.
My understanding is that the issue is with the compiler, because some compilers produce redundant bytecode.
Sharing a maven project is not enough because there's no way to tell what compiler was used: even though the above project is java 14 based on the pom, you might be running maven on top of a jdk 21.
Similarly your initial question says you are on java 17 but I'm not reproducing the problem, so I'm probably missing some crucial details.
This is really confusing since the messge from the people admin the SQ server was:
"Currently we are using:
FindBugs 4.2.3 / SpotBugs 4.7.3"
is it not only one plugin for both?
@gtoison yes I understand I need to be able to reproduce the problem. I do not have access to the SQ instance since I am not admin. That is why I tried with sonar maven plugin since that was the best option.
Btw example is called jaav14 I changed to use 17 for it.
Not sure this is related to compiler since the same compiler is used in both cases:
https://www.azul.com/downloads/#zulu and it is 17.
What is needed from SQ to show what is happening?
FindBugs is the original name of the project. SonarSource made a plugin to use it in SonarQube.
When FindBugs was renamed SpotBugs the plugin kept using the FindBugs name, because there was no practical way to rename a SonarQube plugin.
So 4.2.3 is the version of the SonarQube plugin and it uses SpotBugs 4.7.3 to perform the analysis.
The plugin does not run on the server, it runs wherever the project is built. Normally after the project is compiled and the tests executed sonar runs the analysis (still on the computer running the build) and then only ships the findings (issues, coverage, etc.) to the SonarQube server.
So the false positive issue is happening on the computer running the build and the SonarQube server is just reporting it.
@gtoison we have been running it on windows and linux but the jdk 17 is the same from Azul.
I got this info from SQ admin.
I think that you are referring to the JDK running your SonarQube server, but that shouldn't matter here.
@mpet I think you might be running into an issue with Eclipse's compiler producing redundant bytecode. When SpotBugs analyzes that bytecode it finds the SA_LOCAL_SELF_COMPARISON which is indeed in the compiled .class file.
It seems that this is addressed and should be fixed in upcoming versions of ECJ
See spotbugs/spotbugs#1992