Java programming language: Find zero errors with static analysis

New projects bring new challenges and new knowledge. In my current project, I recently created a definition for handling null checks in static code analysis. It was important to many in the project that parameters were not only used at runtime, for example Objects.requireNonNull(…)) are checked, but also directly during compilation. Therefore, we decided to also use static code analysis to verify handling null to put.

Static code analysis

Before we dive into the shifted annotation and checker libraries that exist for Java, let me briefly explain what static code analysis is all about. Here, the program code is checked by tooling during compilation. The currently most common tool in Java is certainly SpotBugs, which can be integrated into builds with Maven or Gradle and whose results can also be published automatically on platforms such as SonarCloud. With a static code analysis you can find problems like a memory overflow, an infinite loop or “Out of Bound” errors. A simple example is a division by 0. If something like this occurs in the code, the analysis can provide a warning or, depending on the configuration, the ending the entire build with errors In our project we have such a check in GitHub Actions, which shows the results directly in SonarCloud and a pull request.

The correct handling of null

One problem with programming with Java is certainly dealing with null. Personally, I am of the opinion that null has its justification, although Tony Hoare, the inventor of null reference in programming, is now talking about it as a “trillion dollar mistake”.

However, in Java there is no native way to define whether a parameter can be null. In the meantime, attempts have been made to solve this using various means in the class library. examples for this are java.util.Optional, Objects.requireNonNull(…) or also JSR305.

A good example of a programming language that has native support for null references is Kotlin. It explicitly distinguishes between nullable references and nonnull references. The latter is the default, although a variable with such a reference can never be assigned null. If you need a variable that can contain null, you have to work with a nullable reference. This will be about that ? characters specified. The following code includes a Kotlin example for both references:

var a: String = "abc" // Regular initialization means
                      // non-null by default
a = null // compilation error

var b: String? = "abc" // can be set to null
b = null // ok

Since there is no such native support in Java, attempts are made to integrate it as well as possible using static code analysis. In general, two annotations are required here, with one (@Nullable) defines that a value or variable can be null, and the other annotation defines that a value or variable must never be null (@NonNull).

A code example that defines a method and adds the information via annotation that the return value of the method never null can be:

@NonNull String getName() {
    if(isUnique()) {
        return „Item „ + getId();
    } else {
        return null;
    }
}

As you can see in the implementation of the method, it’s quite possible that it null returns. That would be a case where static code analysis reveals a violation. For example, if you want, you can configure IntelliJ to display such problems directly.

The following code that the @Nullable Annotation used leads to a warning in the analysis:

void check(@Nullable String value) {
    Objects.hash(value.toLowerCase());
}

In this example, the annotation @Nullable for the variable value defines that this is the value null may have. However, having the code access the variable directly potentially leads to a NullPointerException at runtime. This would also be evaluated by the static code analysis and reported as a problem.

Installation in your own project

If you want to integrate such a static code analysis in your own project, you have to create a few simple requirements. The first thing to do is decide on one or more analysis tools. Here I recommend Spotbugs, which is the successor of Findbugs. The tool can be started either from the command line or integrated into a Gradle or Maven build. In order to analyze the problems found, you can either look at them in Spotbug’s own swing client or, for example, as an HTML-based overview as part of a generated Maven site using Maven site-Target. You can configure the tool so that it uploads the results to a sonar or the SonarCloud, for example.

Wer @Nullable– and @NonNull– want to use annotations in the project requires a library that provides the annotation. Your own project only needs to be dependent on the library at compile time. Here, too, there is (unfortunately) a whole range of libraries that provide annotations. Examining each library based on their pros and cons will be part of a separate post. Therefore, I first recommend Spotbug’s annotations as a dependency, which can be found at the following Maven coordinates:

    com.github.spotbugs
    spotbugs-annotations
    4.7.3
 

Unfortunately, the abundance of tools and libraries does not make it easy to find the perfect and future-oriented combination. As I delved deeper into the topic, I was shocked that much in this area is still not defined by standards or commonly used best practices. Although there were different approaches, such as with the JSR305, these always fizzled out at some point and are sometimes used in a wild mix today. That’s why I will devote a separate post to this problem in the near future.

(rme)