Suppressing FindBugs warnings

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 place where FindBugs reported problem, and use appropriate bug code.

You should start with adding com.google.code.findbugs:annotations:2.0.0 jar to the project dependencies. Then open 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).

---

Follow-ups:

This article has been republished on Dzone's Javalobby (03/23/2012), with interesting comment from Fabrizio Giudici.

He is 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.

See also Why doesn't a missing annotation cause a ClassNotFoundException at runtime?

FindBugs and JSR-305

Suppose that group of developers work in parallel on parts of big project - some developers are working on service implementation, while others are working on code using this service. Both groups agreed on service API, and started working separately, having in mind the API assumptions...

Do you think this story will have happy end? Well, ... - maybe :) - there are tools which can help achieve it :) - one of them is FindBugs, supported with JSR-305 (annotations for software defect detection).

Let's take a look at the service API contract:


As you see there are annotations like @Nonnull or @CheckForNull added to the service method signatures. The purpose of their usage is to define the requirements for the method parameters (ex. identifier parameter cannot be null), and the expectations for the values returned by methods (ex. service method result can be null and you should check it in your code).

So what? - you may ask - should I check them in the code by myself or trust the co-workers that they will use the guidelines defined by those annotations? Of course not :) - trust no one, use the tools which will verify the API assumptions, like FindBugs.

Suppose that we have following service API usage:


Let's try to verify the code against the service API assumptions:

FindBugs will analyze your code, and switch to the FindBugs perspective showing potential problems:

Null passed for nonnull parameter

Possible null pointer dereference

Similar way, guys writing the service code may verify their work against defined API assumptions, for ex. if you run FindBugs for the very early version of service implementation:


Following error will be found:

As you see, nothing can hide from the FindBugs and his ally - JSR-305 ;)

Few links for the dessert:

• JSR-305: Annotations for Software Defect Detection
• JSR 305: a silver bullet or not a bullet at all?

---

Follow-ups:

This article has been republished on Java Code Geeks (03/15/2012) and Dzone's Javalobby (08/29/2012).