When choosing a compiler (which should be understood to include the linker), a compiler that complies with the Java Language Specification [JLS 2005] should be used whenever possible.
When choosing a source code analysis tool, it is clearly desirable that the tool be able to enforce as many of the guidelines in this document as possible. Not all recommendations are enforceable; some are strictly meant to be informative.
To the greatest extent possible, the static analysis tool should be both complete and sound with respect to enforceable guidelines.
A static analysis tool is considered complete (with respect to a specific guideline) if it does not give a false-negative result, meaning it is able to find all violations of a guideline.
A static analysis tool is considered sound if it does not issue false-positive results, or false alarms. Too many such false alarms rapidly lead users to ignore the results of a tool, potentially missing serious issues.
The possibilities for a given guideline are outlined in the table below.
The final possibility is that a tool has not implemented a checker for a specific guideline.
Compilers and source code analysis tools are trusted processes, meaning that a degree of reliance is placed on the output of the tools. Consequently, developers must ensure that this trust is not misplaced. Ideally, this should be achieved by the tool supplier running appropriate validation tests. While it is possible to use a validation suite to test a compiler or source code analysis tools, no formal validation scheme exists at this time.
While many guidelines list common exceptions, it is difficult if not impossible to develop a complete list of exceptions for each guideline. Consequently, it is important that source code comply with the intent of each guideline and, to the greatest extent possible, tools minimize false positives which do not violate the intent of the guideline. The degree to which tools minimize false positive diagnostics is a quality of implementation issue.