java:S1123 Java Depracated Annotation Rule Not Triggering on Branch/PR Analysis

My team recently ran into an oddity with the Java Rule java:S1123

Deprecation should be marked with both the @ Deprecated annotation and @ deprecated Javadoc tag. The annotation enables tools such as IDEs to warn about referencing deprecated elements, and the tag can be used to explain when it was deprecated, why, and how references should be refactored.

In our case, we marked an existing method with @ Deprecated:

class MyClass {

  @Deprecated             // New line added and scanned by branch analysis, compliant in isolation
  public void foo1() {    // Existing method signature not scanned by branch analysis, now noncompliant

  }
}

Our branch analysis is configured to compare against master (and gates merge to trunk based on SonarQube violations). The diff only showed the annotation and in isolation it was not a violation. However, a total analysis showed the violation because it scanned both the newly added annotation and the existing method signature. In other words, the method signature was existing code ignored by branch analysis and the annotation alone was not a violation but together they violate this rule.

The issue is that this rule violation is not detected by branch analysis because the violation is associated with the existing method signature and a branch analysis only detects new code. So adding the @ Deprecated annotation to a method will introduce a violation that cannot be caught by analyzing new code. Additionally, on the SonarQube dashboard the violation was backdated to when the existing method signature was added. For example, we added the method a year ago and adding the @ Deprecated annotation introduced a one year old violation.

The expected result here would be that adding @ Deprecated to a method would trigger this violation against the line containing the annotation. What do you think?


P.S. Love your product by the way. One of the best IntelliJ plugins IMO.

P.S.S. Had to add a space between “@” and “Deprecated” because it thought I was trying to @ someone.

Found the roadmap item here https://portal.productboard.com/sonarsource/3-sonarqube-server/c/295-new-pull-request-issues-on-unchanged-code?&utm_medium=social&utm_source=share and a similar issue here from September 2023 java:S1123 rule wrong behavior with Pull Requests

Hey @Travis_Pennetti, welcome to the Community and thanks for your kind words in the P.S!

There’s an important remark to make: a branch analysis doesn’t only analyze new code. A PR analysis does, therefore it won’t find these types of multi-lines issues. A branch analysis will analyze all the code, changed or not (even when using the reference branch new code definition), but afterwards it will differentiate between issues on new code and on overall code.

So in this case, a change in line X (annotation) is causing an issue to pop up in line Y (method signature, it seems in this case it acts as the main location of the issue). Implications:

  • PR analysis is totally oblivious to this, it cannot raise an issue on line Y because it’s unchanged. This might changed soon, as you saw in our product roadmap. The old Community thread you found was about PR analysis too.
  • Branch analysis, however, will raise the issue, but it will backdate it, so you won’t see it as a new issue/new code. You already noticed this.

I will concede something though: in this particular case, it might be argued that line X (annotation) could also be the main location of the issue instead of line Y (method signature). This way your case would be detected as a new issue in a branch analysis (although the opposite case might not!). I’m gonna flag this for the devs in case they want to chime in or consider this feedback, thanks for sharing!