Community
Participate
Working Groups
Currently, the project settings just allow me to warn or ignore when the compiler encounters an unknown string value in java.lang.SuppressWarnings. Please add an option to supply a file where I can specify additional valid values which the compiler should accept. Example: # Known PMD warnings PMD.CloseResource PMD.UselessOverridingMethod AFAIK, PMD is currently the only tool which uses the @SuppressWarnings annotation but for future compatibility, it might be good to either have a way to specify several of these files or to have an "include" syntax.
Hello, Checkstyle also use this annotation. This is becoming quite annoying because on every website, they tell us to completely disable the "Unsupported @SuppressWarnings" warning! This is defeating the feature. For instance: http://stackoverflow.com/questions/5017569/unsupported-suppresswarnings-pmd-donotcallsystemexit It would be cool, instead of a user-filled text file, that: 1) either each plugin can use an extension point to inject their own list of known warnings 2) or better, each plugin can use an extension point to register a callback, and Eclipse would call this method: boolean isKnownWarning(String warningId) For Eclipse to throw "Unsupported @SuppressWarnings("unknown")" 3) or even better, same as solution 2 + a second callback to check if the warning is necessary or not: boolean isWarningNecessary(String warningId, Project project, JavaThing classMethodOrVariable) So that Eclipse can ALSO throw an "Unnecessary @SuppressWarnings("checkstyle:javadocmethod")" if there would be no "checkstyle:javadocmethod" in the given class, method or variable, or if Checkstyle is disabled for that project... Best regards, Sébastien Laoût.
Android Studio also used this feature: http://stackoverflow.com/questions/25870418/unsupported-suppresswarnings-clonedoesntcallsuperclone-fieldcanbelocal-objecta I know Android Studio is not based on Eclipse anymore, but it's a hint at potential other uses of the plugin extension point.
One last comment, and I wont SPAM you anymore ;-) Here is a list of plugins I found on Internet, that would also profit from the extension point: UCDetector: https://sourceforge.net/p/ucdetector/discussion/791296/thread/a78ef693/ JBIDE (whatever this tool is...): https://issues.jboss.org/browse/JBIDE-10187 SQUID: @SuppressWarnings("squid:xxxx") http://sonarqube-archive.15.x6.nabble.com/Removing-Eclipse-Warnings-for-SuppressWarnings-quot-squid-XXX-quot-td5032976.html To avoid the problem, FindBugs went so far to use their own SuppressWarnings in their own package (quite misleading!): edu.umd.cs.findbugs.annotations.SuppressWarnings("SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE") http://comments.gmane.org/gmane.comp.java.findbugs.general/2578
(In reply to Sébastien Laoût from comment #3) > One last comment, and I wont SPAM you anymore ;-) > > Here is a list of plugins I found on Internet, that would also profit from > the extension point: > > UCDetector: > https://sourceforge.net/p/ucdetector/discussion/791296/thread/a78ef693/ > > JBIDE (whatever this tool is...): > https://issues.jboss.org/browse/JBIDE-10187 > > SQUID: @SuppressWarnings("squid:xxxx") > http://sonarqube-archive.15.x6.nabble.com/Removing-Eclipse-Warnings-for- > SuppressWarnings-quot-squid-XXX-quot-td5032976.html > > To avoid the problem, FindBugs went so far to use their own SuppressWarnings > in their own package (quite misleading!): > edu.umd.cs.findbugs.annotations. > SuppressWarnings("SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE") > http://comments.gmane.org/gmane.comp.java.findbugs.general/2578 The Checker Framework also uses @SuppressWarnings http://types.cs.washington.edu/checker-framework/tutorial/webpages/security-error-eclipse.html
ErrorProne also recommends using @SuppressWarnings and this can result in the "Unsupported @SuppressWarnings" warning in Eclipse. See for example https://errorprone.info/bugpattern/FutureReturnValueIgnored
Any updates on this feature? Also if some persons will be found to contribute, will it be included in the mainstream? Could someone from the core team answer the question, so we can maybe fix it on our own?
Another possibility to consider would be to not warn about an unsupported warning token when the token in question is not actually causing a warning to be supressed. I assume this warning is provided to warn about possible typos; presumably if the term matches something, its unlikely to be a typo.
(In reply to Darko Palic from comment #6) > Any updates on this feature? > > Also if some persons will be found to contribute, will it be included in the > mainstream? > Could someone from the core team answer the question, so we can maybe fix it > on our own? Yes, that'll be nice.
See also bug 122475
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
