More than 10 years of experience in Enterprise Applications development, and Project Management (since June 2001). Specialties: Enterprise Applications, J2EE, J2SE, Spring Framework, Spring Security, Spring Webflow, JPA and JDBC, JMX, JAXB, JUnit; XML, XSLT and XSL-FO; HTML/CSS, Javascript, JSON, jQuery/jQuery UI; RDBMS (Oracle, SQL Server, MySQL), PL/SQL; UML; Mobile Applications, mostly in Objective-C targeted iPhone/iPad Michal is a DZone MVB and is not an employee of DZone and has posted 10 posts at DZone. You can read more from them at their website. View Full User Profile

Suppressing FindBugs Warnings

03.23.2012
| 7167 views |
  • submit to reddit
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)

(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

The reason for which we can't unfortunately use the same annotation from java.lang is that it has SOURCE retention, so FindBugs can't see it in the bytecode. Lack of fantasy from the JDK designers, which at the time didn't figure it out that warnings could be generated by a code analyzer after the compilation process.

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

Qiang Di Pa replied on Sat, 2013/11/16 - 3:35am

 You can receive a http://winterequip.com lot closer to your fundraising goals by developing actual relationships with the individuals who can help you access capital. Im not speaking about the. Im speaking about recalling birthdays, being genuinely curious about how someones kid did in their immense soccer game

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.