@jessewilson explains in this articles, Rolling out @Nullable and Non-null is the Default, why they decided to use
@NotNull through their codebase to achieve better Null Pointer exception protection and also to play better with languages such as Kotlin.
If you are overwhelmed by the thought of going through every file and adding
@Nullable, don't be.
@Nonnull everywhere is boilerplate everywhere. This extra code distracts from the real problems we’re solving. Thankfully, there’s a solution: JSR 305’s
@ParametersAreNonnullByDefault indicates that everything in an entire package is non-null unless otherwise specified
In case you are asking yourself why should you bother with
@Nullable and @NotNull annotations let you check nullability of a variable, parameter, or return value. They help you control contracts throughout method hierarchies, and if IntelliJ IDEA spots that the contract is being violated, it will report the detected problem, and will point to the code where NullPointerException may occur.
Not everything is good news, a cautionary tale:
Do you use JSR 305 annotations like
@Nullable together with annotations from the javax.annotation package, for example
@PostConstruct? If so, then migrating to Java 9 won’t be straight-forward due to split packages.