How to enable custom Java rules on classes annotated with `SuppressWarnings("all")`

SonarQube Server / Community Build Writing rules
,
1

Description

I’m using SonarQube Server Community Edition 25.2.0.102705, deployed locally for testing purposes before moving it to Docker on the cloud.

Issue

I want to ensure that all custom Java rules (and built-in rules) are still applied to classes annotated with SuppressWarnings("all"). However, currently, when this annotation is present, no custom rules are triggered, even if there are violations in the class.

This behaviour worked as expected in SonarQube v9.9.8, meaning that custom rules were still applied even when SuppressWarnings("all") was present.

What I’ve tried

  • I found that the Java plugin contains a filter called SuppressWarningFilter, which is instantiated in PostAnalysisIssueFilter. However, I’m not sure how to disable or override this behaviour.
  • I also looked into the built-in rule java:S1309 (track uses of “SuppressWarnings” annotations), which allows specifying permitted SuppressWarnings messages. However, in our codebase, we have multiple instances of this annotation with varying messages, making it difficult to group them effectively.

Goal

I need a way to ensure that all custom rules are applied, even if a class is annotated with SuppressWarnings("all"), just as it worked in SonarQube v9.9.8.

Has there been a change in behaviour in recent versions? Is there a way to disable this suppression mechanism for custom rules?

Any guidance would be greatly appreciated.

2

Hi,

Welcome to the community!

I suspect you were exploiting a bug. “All” should always mean all.

 
Ann

5

Hello @marko_domic , as Ann said, the normal behaviour is that SupressWarnings(“all”) is disabling analysis in that file.

Here is the documentation about it : Java | SonarQube Server Documentation

7

Hello,

Welcome to the community!

Thank you! :slight_smile:

I understand what you’re saying, but is there a way to prevent the usage of SuppressWarnings("all") annotation? So, when someone put this annotation in code, SonarQube could say, ‘hey, this annotation is not allowed’ ?

8

Hi,

That would be this:

If it’s that significant to you, then you might want to make the rule a Blocker in your profile.

 
HTH,
Ann

9

That’s the thing, rule java:S1309 has only 1 property, where you can specify which SuppressWarnings should allow, all other ones should be permitted. In our codebase, we have large number of different SuppressWarnings comments (annotation with different values), so we can’t specify all of them in java:S1309 rules property. The only thing which I want to prevent is SuppressWarnings("all") and that’s it.

As I’m not that proficient in SonarQube, what is rule Blocker exactly?

10

Hi,

When you activate a rule in a profile, you have the ability to use the default severity, or to choose your own severity. Blocker is the highest available severity.

 
HTH,
Ann

11

Oh, you ment to setup severity, I understand. But the main problem here is that I can use this rule properly for my use case

12

Hi,

Sorry, but I don’t know what to tell you.

I think your only option would be to write a custom analog rule that only raised an issue on all, or had a parameter of what to ban.

 
HTH,
Ann

13

Hi,

That is what I’ve said in main topic, I’ve already created custom rule which checks for “all” value and it worked on older version of SonarQube, but now, the same custom rule, doesn’t work on new version, mostly because SuppressWarning("all") bans it

14

Hi,

My suggestion is to disable S1039 in favor of your custom rule.

 
HTH,
Ann

15

You mean java:S1309 ? Yep, it is disabled and custom rule still doesn’t trigger, because of SuppressWarning(“all”) annotation on class.

16

Hi,

Have you looked up how S1309 is written?

 
Ann

17

Yes I did. And created custom rule in the same way as S1309 is implemented, but still, rule hasn’t been triggered at all when we have SuppressWarning(“all”) annotation on class. Here is temporary implementation, for only triggering custom rule when it detects any kind of annotation:

import org.sonar.check.Rule;
import org.sonar.plugins.java.api.IssuableSubscriptionVisitor;
import org.sonar.plugins.java.api.tree.AnnotationTree;
import org.sonar.plugins.java.api.tree.Tree;
import org.sonar.plugins.java.api.tree.Tree.Kind;

import java.util.Collections;
import java.util.List;

@Rule(key = "AnnotationCustomRule")
public class AnnotationCustomRule extends IssuableSubscriptionVisitor {

    @Override
    public List<Tree.Kind> nodesToVisit() {
        return Collections.singletonList(Kind.ANNOTATION);
    }

    @Override
    public void visitNode(Tree tree) {
        AnnotationTree annotationTree = (AnnotationTree)tree;
        reportIssue(annotationTree, "Annotation used.");
    }
}

So, this rule triggers on all annotations which exist, except on classes which are annotated with SuppressWarning("all").

19

Hi,

I’ve flagged this for the language experts.

 
Ann

1 Like
21

Hello @marko_domic ,

Sorry for the late reply, the investigation took a bit more time than expected.

Currently, there isn’t an API to control the issue filtering mechanism from a custom plugin.

As a workaround, you can fork the sonar-java project and modify the accept method in org.sonar.java.filters.PostAnalysisIssueFilter. The simplest approach to solve your problem is to check the issue’s rule key and return true for the custom rules you want to retain. This modification should be straightforward, requiring just a few lines of code. Once you’ve made these changes, build sonar-java and replace the existing sonar-java-plugin in SonarQube_folder/lib/extensions directory with your customized version.

Otherwise, we have this open ticket to expose the filtering mechanism to custom plugins. I’ll check on the status and see if we can implement it in the near future.

Erwan

1 Like