NetBeans - More static code analysis

Fri, Feb 5, 2016 ❝Extending static code analysis capabilities in Netbeans.❞

Contents

NetBeans is an IDE that has long been the underdog to Eclipse and IntelliJ. And although many will prefer one of the latter, by now it has caught up quite significantly and is already a pleasant IDE to work in.

To get even more out of Netbeans, there are the abilities of “source inspection” and “inspection and transform”. These may not be the most famous options available. And I know I spent quite some time googling just to find out how to enable/do static analysis on null values. So, here is a quick post detailing on what to expect and how to use these functions.

Source code inspection

The first static analysis feature is “Inspect”. You can find this option in Source -> Inspect. (Make sure that a file window is the focused window when you do this. Otherwise, the scope field containing your projects may not be populated correctly.)

You will be presented with a dialog showing you a number of options:

• Scope: Select the scope of your inspection. Typically a full project, or all opened projects, depending on your intentions.
• Use - Configuration: Select the type of analysis to be performed. The following options are available (for me).
• All Analyzers: This does every analysis that is available.
• Netbeans Java Hints: These are the general Java source code hints provided by Netbeans. Additional hints can be installed by installing Additional Java hints for NetBeans IDE plugin. These hints will also be included in this NetBeans Java Hints category.
• JRE 8 Profiles Conformance: Verify that a project conforms to a certain JRE 8 profile. I have not personally used this project and cannot give you any details on this one.
• FindBugs: NetBeans 8.1 includes FindBugs Integration plugin by default. Through this option, we can inspect the project with the complete FindBugs static analysis rules set. If this profile is not available immediately, you can find and install the plugin called FindBugs Integration.
• Other than the above profiles, there are options to compile your own profile by composing your desired set of analysis rules.
• Use - Single Inspection: This is mainly useful if you need to analyze one specific rule. This rule can be selected and you can limit your inspection to the select rule. These are the same analysis rules as you find in the configurations discussed earlier.

When you start inspection, a new tool window “Inspector” will appear with the results of the inspection. You can then double-click on a finding in order to look it up in the source code.

Inspect & Transform

Another interesting option is the “Inspect and Transform…” option of the Project context menu. You can find this by right-clicking on the project root and clicking the menu item “Inspect and Transform…”.

Inspect & Transform allows you to automate migrations to newer Java versions by automatically looking up and replacing Java language patterns that are known to be improvable with the added language constructs of a new Java version.

You can start analysis and NetBeans will provide a tool window with a preliminary analysis showing all the candidates for transformation. To start the transformation you can click “Do Refactoring” and NetBeans will start refactoring all discovered candidates (that have been selected).

Advanced analysis capabilities

Apart from the options described above, there are more possibilities of analysis. One that is part of the FindBugs capabilities but was not widely advertised in NetBeans (AFAICT) is the ability to do null analysis using annotations.

The capability originates from JSR-305: Annotations for Software Defect Detection. JSR-305 is an attempt to unify annotations used for such analyses to a common set that is used by all IDEs.

FindBugs (and with it NetBeans) supports analysis of at least:

• The annotations for nullability analysis: @Nonnull, @Nullable and the likes.
  By annotating code with these annotations, one can express intention for acceptance of null values in the implementation. The static analysis capabilities of FindBugs will then be able to reason about method calls and whether or not there is the possibility of null being provided as a method call argument. You will be provided with an error in case static analysis discovers a case where you do not adhere to this contract.
• Mandatory checking of return values: @CheckReturnValue.
  Methods that do analysis and the return value is significant for the continuation of the control flow can be annotated with this annotation. This indicates that any call of this method that does not use its return value, will be listed as an error. This is particularly useful in case methods perform a verification/validation function and the result must be checked for the method to be relevant.

NetBeans obviously supports JSR-305. It is part of the FindBugs rules set, and is actually enabled by default. Furthermore, IntelliJ supports these annotations by default and has some of their own. Depending on your use case you may want to go with JSR-305 standard annotations or those offered by IntelliJ. Eclipse, at the very least, supports the nullability annotations, as they can be configured in the IDE and at the project level. That is, one can configure which annotation indicates cases where null is not allowed, and the annotation that indicates where null explicitly is allowed.

To include JSR-305 in your project, you can either add the library manually. In case of Maven one can add dependency:

<dependency>
    <groupId>com.google.code.findbugs</groupId>
    <artifactId>jsr305</artifactId>
    <version>3.0.1</version>
</dependency>

… or for Gradle:

compile 'com.google.code.findbugs:jsr305:3.0.1'

jsr305 version 3.0.1 is the latest version at the time of writing.

This kind of static analysis is extremely useful for a project that is starting to mature. One can annotate source code with these annotations and let static analysis find any overlooked error cases.