NullAway is a tool to help eliminate NullPointerExceptions (NPEs) in your Java code. To use NullAway, first add @Nullable annotations in your code wherever a field, method parameter, or return value may be null. Given these annotations, NullAway performs a series of type-based, local checks to ensure that any pointer that gets dereferenced in your code cannot be null. NullAway is similar to the type-based nullability checking in the Kotlin and Swift languages, and the Checker Framework and Eradicate null checkers for Java.
NullAway is fast. It is built as a plugin to Error Prone and can run on every single build of your code. In our measurements, the build-time overhead of running NullAway is usually less than 10%. NullAway is also practical: it does not prevent all possible NPEs in your code, but it catches most of the NPEs we have observed in production while imposing a reasonable annotation burden, giving a great "bang for your buck."
NullAway requires that you build your code with Error Prone, version 2.4.0 or higher. See the Error Prone documentation for instructions on getting started with Error Prone and integration with your build system. The instructions below assume you are using Gradle; see the docs for discussion of other build systems.
To integrate NullAway into your non-Android Java project, add the following to your build.gradle file:
plugins {
// we assume you are already using the Java plugin
id "net.ltgt.errorprone" version "0.6"
}
dependencies {
annotationProcessor "com.uber.nullaway:nullaway:0.9.8"
// Optional, some source of nullability annotations.
// Not required on Android if you use the support
// library nullability annotations.
compileOnly "com.google.code.findbugs:jsr305:3.0.2"
errorprone "com.google.errorprone:error_prone_core:2.4.0"
errorproneJavac "com.google.errorprone:javac:9+181-r4173-1"
}
import net.ltgt.gradle.errorprone.CheckSeverity
tasks.withType(JavaCompile) {
// remove the if condition if you want to run NullAway on test code
if (!name.toLowerCase().contains("test")) {
options.errorprone {
check("NullAway", CheckSeverity.ERROR)
option("NullAway:AnnotatedPackages", "com.uber")
}
}
}Let's walk through this script step by step. The plugins section pulls in the Gradle Error Prone plugin for Error Prone integration. If you are using the older apply plugin syntax instead of a plugins block, the following is equivalent:
buildscript {
repositories {
gradlePluginPortal()
}
dependencies {
classpath "net.ltgt.gradle:gradle-errorprone-plugin:0.6"
}
}
apply plugin: 'net.ltgt.errorprone'In dependencies, the annotationProcessor line loads NullAway, and the compileOnly line loads a JSR 305 library which provides a suitable @Nullable annotation (javax.annotation.Nullable). NullAway allows for any @Nullable annotation to be used, so, e.g., @Nullable from the Android Support Library or JetBrains annotations is also fine. The errorprone line ensures that a compatible version of Error Prone is used, and the errorproneJavac line is needed for JDK 8 compatibility.
Finally, in the tasks.withType(JavaCompile) section, we pass some configuration options to NullAway. First check("NullAway", CheckSeverity.ERROR) sets NullAway issues to the error level (it's equivalent to the -Xep:NullAway:ERROR standard Error Prone argument); by default NullAway emits warnings. Then, option("NullAway:AnnotatedPackages", "com.uber") (equivalent to the -XepOpt:NullAway:AnnotatedPackages=com.uber standard Error Prone argument), tells NullAway that source code in packages under the com.uber namespace should be checked for null dereferences and proper usage of @Nullable annotations, and that class files in these packages should be assumed to have correct usage of @Nullable (see the docs for more detail). NullAway requires at least the AnnotatedPackages configuration argument to run, in order to distinguish between annotated and unannotated code. See the configuration docs for other useful configuration options.
We recommend addressing all the issues that Error Prone reports, particularly those reported as errors (rather than warnings). But, if you'd like to try out NullAway without running other Error Prone checks, you can use options.errorprone.disableAllChecks (equivalent to passing "-XepDisableAllChecks" to the compiler, before the NullAway-specific arguments).
Snapshots of the development version are available in Sonatype's snapshots repository.
The configuration for an Android project is very similar to the Java case, with one key difference: The com.google.code.findbugs:jsr305:3.0.2 dependency can be removed; you can use the android.support.annotation.Nullable annotation from the Android Support library.
dependencies {
annotationProcessor "com.uber.nullaway:nullaway:0.9.8"
errorprone "com.google.errorprone:error_prone_core:2.4.0"
errorproneJavac "com.google.errorprone:javac:9+181-r4173-1"
}A complete Android build.gradle example is here. Also see our sample app. (The sample app's build.gradle is not suitable for direct copy-pasting, as some configuration is inherited from the top-level build.gradle.)
Some annotation processors like Dagger and AutoValue generate code into the same package namespace as your own code. This can cause problems when setting NullAway to the ERROR level as suggested above, since errors in this generated code will block the build. Currently the best solution to this problem is to completely disable Error Prone on generated code, using the -XepExcludedPaths option added in Error Prone 2.13 (documented here, use options.errorprone.excludedPaths= in Gradle). To use, figure out which directory contains the generated code, and add that directory to the excluded path regex.
Note for Dagger users: Dagger versions older than 2.12 can have bad interactions with NullAway; see here. Please update to Dagger 2.12 to fix the problem.
Unlike other annotation processors above, Lombok modifies the in-memory AST of the code it processes, which is the source of numerous incompatibilities with Error Prone and, consequently, NullAway.
We do not particularly recommend using NullAway with Lombok. However, NullAway encodes some knowledge of common Lombok annotations and we do try for best-effort compatibility. In particular, common usages like @lombok.Builder and @Data classes should be supported.
In order for NullAway to successfully detect Lombok generated code within the in-memory Java AST, the following configuration option must be passed to Lombok as part of an applicable lombok.config file:
addLombokGeneratedAnnotation
This causes Lombok to add @lombok.Generated to the methods/classes it generates. NullAway will ignore (i.e. not check) the implementation of this generated code, treating it as unannotated.
Let's see how NullAway works on a simple code example:
static void log(Object x) {
System.out.println(x.toString());
}
static void foo() {
log(null);
}This code is buggy: when foo() is called, the subsequent call to log() will fail with an NPE. You can see this error in the NullAway sample app by running:
cp sample/src/main/java/com/uber/mylib/MyClass.java.buggy sample/src/main/java/com/uber/mylib/MyClass.java
./gradlew buildBy default, NullAway assumes every method parameter, return value, and field is non-null, i.e., it can never be assigned a null value. In the above code, the x parameter of log() is assumed to be non-null. So, NullAway reports the following error:
warning: [NullAway] passing @Nullable parameter 'null' where @NonNull is required
log(null);
^
We can fix this error by allowing null to be passed to log(), with a @Nullable annotation:
static void log(@Nullable Object x) {
System.out.println(x.toString());
}With this annotation, NullAway points out the possible null dereference:
warning: [NullAway] dereferenced expression x is @Nullable
System.out.println(x.toString());
^
We can fix this warning by adding a null check:
static void log(@Nullable Object x) {
if (x != null) {
System.out.println(x.toString());
}
}With this change, all the NullAway warnings are fixed.
For more details on NullAway's checks, error messages, and limitations, see our detailed guide.
Please feel free to open a GitHub issue if you have any questions on how to use NullAway. Or, you can join the NullAway Discord server and ask us a question there.
We'd love for you to contribute to NullAway! Please note that once you create a pull request, you will be asked to sign our Uber Contributor License Agreement.
NullAway is licensed under the MIT license. See the LICENSE.txt file for more information.