Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@SuppressAnnotation to support list of violations #157

Open
nitirajrathore opened this issue Mar 18, 2020 · 3 comments
Open

@SuppressAnnotation to support list of violations #157

nitirajrathore opened this issue Mar 18, 2020 · 3 comments
Assignees

Comments

@nitirajrathore
Copy link

nitirajrathore commented Mar 18, 2020

Hi,

We are using suppression like this in elasticsearch project. But we are faced with a complication. We are extending a forbidden class and to make Suppression work we used @SuppressAnnotation at class level. But because of this class level annotation all other violations of the class are also skipped, like use of System.out or String.format(...) with default locale.

What we need is to suppress only a particular violation. Something like

public @interface SuppressForbidden {
    String reason();
    String[] voilations;
}

So that only the listed violations are suppressed and others still get caught by forbidden-apis.

Is such feature already available? or can it be implemented in future release?

@mikemccand
Copy link

+1, I've hit this limitation before too (working on Lucene's sources!). It'd be great if forbiddenapis had more granularity ... maybe it does and we just don't know how @uschindler?

@uschindler
Copy link
Member

uschindler commented Mar 19, 2020

Hi,
The problem is that we just have a list of signatures, but no categories. The forbidden signatures may come from different sources, but we don't know their names. It's just an input stream coming from Maven/Gradle or classloader.

For bundled signatures we have some name, but generally before adding suppression mechanism (like javac suppressions) all signatures need to be categorized in a standard way (for both bundled and user defined signatures).

After that the suggestion here might be implemented, but there must be a way to tell forbiddenapis which attribute of the Annotation triggers the exclusion. Because we decided to use any Annotation defined in the project. This prevents to require forbiddenapis at compile time in classpath.

In short not sure if this could be implemented. For next major version we may change signatures file format to add categories (in same way like the error messages per signature).

The example given above is one problem that cannot be solved by refactoring - so sorry! But in general the best workaround is to use method level annotations and refactor code to have the suppressions only on arbitrary added method bodies around the problematic code.

@uschindler uschindler self-assigned this Mar 19, 2020
@bmarwell
Copy link

Hi, I'd love to see this feature, too! Can anyone of you create a PR? :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants