Suppressing FindBugs Warnings
A few days ago I spoke with my friend, Tomek, about suppressing FindBugs warnings. Here is brief summary of our conversation, which may be interesting for you.
There is one simple method for suppressing the FindBugs warnings - usage of edu.umd.cs.findbugs.annotations.SuppressWarnings annotation. Just add it in the place where FindBugs reported problem, and use the appropriate bug code.
You should start by adding com.google.code.findbugs:annotations:2.0.0 jar to the project dependencies. Then open the bug reported by FindBugs, and find its code, like in this example:
Finally add something like this to the method holding the code marked by FindBugs:
That's all, clear the FindBugs markers, and run it again, the problem will not be reported in this place again.
Nice! Isn't it? - No, it isn't :( - Why you may ask? - Because there is another annotation in java.lang package with exactly the same name (!), used for suppressing different kind of warnings. Shouldn't it be used instead? - Well ...
Another question is if we want to add another jar to the project dependencies just for suppressing FindBugs warnings - thank God the FindBugs authors marked this annotation with retention policy 'CLASS', which means the jar will not be required when running the project (ex. in web application container).
Published at DZone with permission of Michal Jastak, author and DZone MVB. (source)There is one simple method for suppressing the FindBugs warnings - usage of edu.umd.cs.findbugs.annotations.SuppressWarnings annotation. Just add it in the place where FindBugs reported problem, and use the appropriate bug code.
You should start by adding com.google.code.findbugs:annotations:2.0.0 jar to the project dependencies. Then open the bug reported by FindBugs, and find its code, like in this example:
Finally add something like this to the method holding the code marked by FindBugs:
That's all, clear the FindBugs markers, and run it again, the problem will not be reported in this place again.
Nice! Isn't it? - No, it isn't :( - Why you may ask? - Because there is another annotation in java.lang package with exactly the same name (!), used for suppressing different kind of warnings. Shouldn't it be used instead? - Well ...
Another question is if we want to add another jar to the project dependencies just for suppressing FindBugs warnings - thank God the FindBugs authors marked this annotation with retention policy 'CLASS', which means the jar will not be required when running the project (ex. in web application container).
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Fabrizio Giudici replied on Sat, 2012/03/24 - 12:17pm
In any case CLASS retention has nothing to do with the fact that you don't need the jar at runtime. Even RUNTIME retention doesn't require the jar; if it's missing, it's just as those annotations weren't there. See http://stackoverflow.com/questions/3567413/why-doesnt-a-missing-annotation-cause-a-classnotfoundexception-at-runtime
Michal Jastak replied on Mon, 2012/04/02 - 12:13am
in response to:
Fabrizio Giudici
Fabrizio,
I'm glad that someone has left such a valuable comment on my modest post :). You are right that, marking SuppressWarnings annotation with SOURCE retention is something unbelievable :(, and harming potential tools like FindBugs. Anyway, don't you think that using by FindBugs annotation having exactly the same short name as the one already existing in JDK is something misleading? Imagine, that one day I introduce String class in my own Java library, having different meaning than the original one (coming from JDK) ... I know that we will probably not be able to avoid all such cases, but maybe it's worth trying ;)
It's interesting that tools like PMD, can work with the original SuppressWarnings annotation, even if it has this unfortunate retention type, but PMD works probably in a little different way than FindBugs.
You are right that even RUNTIME retention doesn't require the jar itself, as long as the classes coming from it are not referenced directly, ex. if you have class A annotated with annotation B coming from some jar, and you don't include this jar in runtime classpath, using A.class.getAnnotation(B.class) will cause an error as expected (because class B is not available on classpath), while A.class.getAnnotations() will silently ignore B in this case
We do learn our whole life :) - and thanks to your comment I'm a little more experienced developer now, thank you
Regards