squid:ClassVariableVisibilityCheck not triggered on non final public field with annotation

I am using SonarQube 7.9.1 with java plugin 3.13.1 and sonarlint in intellij.

I got a CAST audit report triggering class design problems due to non final instance fields with public visibility. But Sonar didn’t raise the issue squid:ClassVariableVisibilityCheck.

After going to the faulty class, it appeared that all fields in that class have the com.fasterxml.jackson.annotation.JsonProperty annotation.
If I remove the annotation on the field, the issue is correctly triggered. But as soon as I put any allowed annotation on the field declararation (even a dummy @SuppressWarnings(" ") ), the issue disappears.

I have double checked the documentation associated with the issue and there is only one exception for not triggering the issue with a public field : to have the final modifier. There isn’t any mention about the effect of using any annotation.

The documentation needs to be updated to be in line with the implemented rule, or the rule must be changed to correspond to the documentation

Hello @JeanMichel,

I checked the implementation of rule java:S1104 (“squid:ClassVariableVisibilityCheck” in older versions of the SonarSource Analyzer for Java), and indeed, a field annotated with whatever annotation is going to be ignored. From what I can see in our git history, this has been the case since the very first implementation of the rule (2015). However, the description cruelly lack this information.

Now, the rationale behind this implementation choice is that, as soon as a field is annotated, there is a big chance that this annotation would be related to an injection-related framework (spring,guice, lombok, etc.). Another approach could have been to white-list annotations which would be ignored by the rule, but this goes against our principle of keeping rules simple and with as less as possible configuration. The downside of this approach is that it goes in favor of False-Negatives, but it also guarantees that actual findings will be real True-Positive.

I changed the description of the rule in our database in order to explicit mention that exception, and updated our rule in order to have it part of the next released version of the SonarSource Analyzer for Java (6.3).

EDIT: PR including the change: https://github.com/SonarSource/sonar-java/pull/2902