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:
Follow-ups:
This article has been republished on Java Code Geeks (03/15/2012) and Dzone's Javalobby (08/29/2012).
