Community
Participate
Working Groups
The Argus Codewatch project (arguscodewatch.sourceforge.net) adds additional warnings and errors to the Eclipse Java compiler. It also uses the @SuppressWarnings annotation to suppress the warnings. However, if in Eclipse the compiler option "Unhandled warning token in '@SuppressWarnings'" is set to warning, our self-defined warnings will be flagged. The current workaround is suppressing the warning for unhandled warning tokens. We propose to add a new Extension Point for declaring new warning tokens. Possibly, this Extension Point also defines a problemid to enable the UI to create a quickfix for suppressing the warning. Implementing this feature enables plug-in developers to add additional compiler checks resulting, hopefully, in better Java code.
I'm writing a PMD plug-in for Eclipse which lets users suppress PMD warnings by adding annotations like @SuppressWarnings("PMD.ReturnEmptyArrayRatherThanNull"). The users of this plug-in face the same problem: either disable the compiler option and have incorrect tokens not flagged or enable it and have correct PMD tokens flagged as unhandled. Since the set of valid PMD tokens can be different for every workspace project and even change between each compilation for a single project I would need an extension point that allows me to dynamically validate those tokens. I.e. not a static list of tokens declared in a plugin.xml but an extension where i can provide my own implementation of an interface that defines a method to check if a certain token is handled. E.g. something like the following: public interface ISuppressWarningTokenValidator { /** * Returns true if the token is handled for a specific resource. * The returned value is only valid for the current compilation * and might be different for the next compilation. * * @param resource The resource which contains the token. This is * typically a file but might also be a project. * @param token The SuppressWarnings token. */ boolean isHandled(IResource resource, String token); }
We've seen several requests for opening up the compiler in order to "understand" foreign annotations in several of our analyses. Generally I think this is a good idea, because it would help users of such third party annotations without burdening JDT with maintaining the code for countless annotations. To me, doing so via an extension point seems preferable over a preference based approach, because a plugin provider can be expected to apply more diligence than a regular user (users as well as JDT devs would be soon frustrated if sloppy annotation configurations will too easily lead to bogus compiler behavior). The road block I keep hitting when thinking about his is the batch compiler: it would be bad, if the compiler is "smarter" in the IDE but if such smart cannot be added to the batch compiler (which cannot use an Equinox extension point). Without having looked at any details: could an annotation processor be a suitable vehicle for plugging a "validation helper" into the compiler? Like: we'd recognize if an annotation processor implements some additional interface and if so use it as a callback for some well-defined situations? Just for illustration: another use of such extensibility would be in the question whether or not a given annotation on a private field should silence the "unused" warning.
(In reply to Stephan Herrmann from comment #2) > Without having looked at any details: could an annotation processor be a > suitable vehicle for plugging a "validation helper" into the compiler? Like: > we'd recognize if an annotation processor implements some additional > interface and if so use it as a callback for some well-defined situations? The idea of standard yet optional/pluggable annotation processor is interesting. Remember, though, the decision of every reporting/notification should still be made by the compiler, but of course we will avoid the additional preferences.
The annotation processor sounds like a good integration point. A problem with inheriting from an additional interface would be that that interface would have to be defined somewhere, and every processor would need to add a compile-time dependency on the provider. But we could try to close the loop and add this directly to javax.annotation.processing.Processor. Since that won't happen without a proof-of-concept implementation, a first iteration could also use reflection to call a new API method by name, even if the method is only declared on a concrete annotation processor (and not yet inherited from the Processor interface).
I am developing an Eclipse-Plugin for validating Java code against internal API and would also appreciate such Extension Point to suppress warnings my plugin uses to indicate API usage violation. The developers of JBoss Tools have to deal with the same problem: https://issues.jboss.org/browse/JBIDE-10187
See also bug 392045
I'm just analysing our Customization Code using standard tools (Sonar/Findbugs/...) and want to sync warnings throuout the chain IDE -> javac -> Sonar/Findbug Due to the fact that we have a lot of old legacy code we are not able to rewrite we have some violations in our current naming rules. We turn them of using the @SuppressWarnings("sqid:"... and end up in the Eclipse settings problem. So we are also interested in the feature to add custom tokens..
I am also interested in any configuration which allows SonarQube @SuppressWarnings tokens when Unhandled token in '@SuppressWarnings': is set.
