Page History

Best practices in Java development circa 2021 dictate sparing use of null . Kotlin even makes you do extra work to declare a nullable reference type. In Kotlin, by default, variables with reference-type cannot have a null value.

Unfortunately we Geode developers maintain a lot of code that was not developed that way. As a result, as maintainers, we often find ourselves wondering whether a particular variable can take on a null value at runtime. One approach is to always assume every reference-typed variable can be null. But that leads to needlessly verbose code.

With GEODE-8882 we have introduced a compile-time dependency (in the geode-core subproject) on the JetBrains annotations package. This makes the JetBrains @NotNull and @Nullable annotations available in classes in that subproject. If you need those annotations in other subprojects, just add this to the pertinent build.gradle:

compileOnly('org.jetbrains:annotations')

These annotations can help you declare your intentions in new code but they are particularly helpful during refactoring. If you wonder whether a variable or method parameter can ever be null, you can annotate it with @NotNull and IntelliJ will perform static analysis (inspection) and will point out (as a warning) places where that variable or parameter is taking on a potentially-null value.

...

If you set up your IDE this way then you will see IllegalArgumentExceptions when tests encounter violations of @NotNull at runtime. This runtime checking is not, in general, in effect in the Geode product unless the user goes out of their way to make it so, by adding a Java annotation processor.

...