SonarQube Detect Old Issues As New Issues When Class Was Changed As a Final Class

Hi
I am using SonarQube 8.2 for analysing a Java project. The project has a class which has not been changed for years and the class has a critical issue that hasn’t been fixed.

During the new code period which is roughly started a week ago, I made the specific class I mentioned before to be a final Class in a topic branch and that was the only change. Just added final keyword. Now the SonarQube is showing the old critical issue as a new issue. This issue is a null pointer dereference issue because of using a null check in an external library which sonar does not recognize.

And more problems came when creating a pull request from the branch that I have made class final as pull request analysis didn’t report any issue. After merging pull request since pull request analysis didn’t report any issue, the same issue reported in the topic branch was reported in the main branch. So my questions are

  1. Why SonarQube detect an old issue as a new issue when changing class to final?
  2. Why the issue is not reported in pull request analysis?

Any explanation regarding this is much appreciated

Thanks,

Hi,

The docs sections on which issues are considered new and on backdating may help.

 
Ann

Thanks for replying,

I went through the documentation. As of documentation, I guess, the sonar issue I was mentioning should be matched to the old issue by the first rule

if the issue is on the same rule, with the same line number and with the same line
hash (but not necessarily with the same message) > MATCH

Because the only change I am doing making the class final. But I doubt whether line hashes change completely when making the class final and as a result that old issue is detected as a new issue. This is the thing that I need to verify. Also, I have a concern why the pull request is not reporting that issue.

Thanks,

Hi,

Can you show us the commit date on the line the issue is raised on? E.G.

 
Ann

Hi,
Sorry for the late reply. Here are the screenshots of the commit date and issue created date.

Thanks

Hi,

Now we’re getting somewhere!

I’ll admit that my heart dropped a little when I saw the dates in your screenshots. But then I read the issue message. This is about an NPE. Such an issue isn’t necessarily caused on the line where the issue is raised. This should be a multi-location issue. I’m betting that either

  • one of the lines in the location set is from 30 July
  • a null-check was deleted on 30 July

Does this make sense?

 
Ann

Hi

Yes, as you said this NPE issue involves multiple lines (11 lines in this case). Also this issue was ignored as null check is done using a class method in a third party library. but somehow sonar does not detect that there is a null check. As I said earlier the only change was making the class final. none of the lines were changed except that. July 30 was the date this change was done. That is the issue

Hi,

I think perhaps the change to the class was coincidental. As I said, I think something else directly related to that issue also changed on the 30th.

 
Ann