I can see that @Nullable
and @Nonnull
annotations could be helpful in preventing NullPointerException
s but they do not propagate very far.
The effectiveness of these annotations drop off completely after one level of indirection, so if you only add a few they don't propagate very far.
Since these annotations are not well enforced there is a danger of assuming a value marked with @Nonnull is not null and consequently not performing null checks.
The code below causes a parameter marked with @Nonnull
to be null
without raising any complaints. It throws a NullPointerException
when it is run.
public class Clazz {
public static void main(String[] args){
Clazz clazz = new Clazz();
// this line raises a complaint with the IDE (IntelliJ 11)
clazz.directPathToA(null);
// this line does not
clazz.indirectPathToA(null);
}
public void indirectPathToA(Integer y){
directPathToA(y);
}
public void directPathToA(@Nonnull Integer x){
x.toString(); // do stuff to x
}
}
Is there a way to make these annotations more strictly enforced and/or propagate further?
@Nullable
or @Nonnull
, but if they are worth it is very "likely to solicit debate"
@Nonnull
when calling an @Nonnull
method with a nullable variable. Of course, casting with an annotation is not possible in Java 7, but Java 8 will be adding the ability to apply annotations to the use of a variable, including casts. So this may become possible to implement in Java 8.
(@NonNull Integer) y
is syntactically possible, but a compiler is not allowed to emit any specific byte code based on the annotation. For runtime assertions tiny helper methods are sufficient as discussed in bugs.eclipse.org/442103 (e.g., directPathToA(assertNonNull(y))
) - but mind you, this only helps to fail fast. The only safe way is by performing an actual null check (plus hopefully an alternative implementation in the else branch).
@Nonnull
and @Nullable
you are talking about, as there are multiple similar annoations (See this question). Are you talking about the annotations in package javax.annotation
?
Short answer: I guess these annotations are only useful for your IDE to warn you of potentially null pointer errors.
As said in the "Clean Code" book, you should check your public method's parameters and also avoid checking invariants.
Another good tip is never returning null values, but using Null Object Pattern instead.
Other than your IDE giving you hints when you pass null
to methods that expect the argument to not be null, there are further advantages:
Static code analysis tools can test the same as your IDE (e.g. FindBugs)
You can use Aspect-oriented programming (AOP) to check these assertions
This can help your code be more maintainable (since you do not need null
checks) and less error-prone.
assert
. I find @Nullable
and @Nonnull
to be useful ideas, but I'd like more force behind them, rather than us hypothesizing about what one could do with them, which still leaves open the possibility of doing nothing with them.
I think this original question indirectly points to a general recommendation that run-time null-pointer check is still needed, even though @NonNull is used. Refer to the following link:
In the above blog, it is recommended that:
Optional Type Annotations are not a substitute for runtime validation Before Type Annotations, the primary location for describing things like nullability or ranges was in the javadoc. With Type annotations, this communication comes into the bytecode in a way for compile-time verification. Your code should still perform runtime validation.
Compiling the original example in Eclipse at compliance 1.8 and with annotation based null analysis enabled, we get this warning:
directPathToA(y);
^
Null type safety (type annotations): The expression of type 'Integer' needs unchecked conversion to conform to '@NonNull Integer'
This warning is worded in analogy to those warnings you get when mixing generified code with legacy code using raw types ("unchecked conversion"). We have the exact same situation here: method indirectPathToA()
has a "legacy" signature in that it doesn't specify any null contract. Tools can easily report this, so they will chase you down all alleys where null annotations need to be propagated but aren't yet.
And when using a clever @NonNullByDefault
we don't even have to say this every time.
In other words: whether or not null annotations "propagate very far" may depend on the tool you use, and on how rigorously you attend to all the warnings issued by the tool. With TYPE_USE null annotations you finally have the option to let the tool warn you about every possible NPE in your program, because nullness has become an intrisic property of the type system.
https://i.stack.imgur.com/bfG9h.png
When activated, all non-annotated parameters will be treated as non-null and thus you will also see a warning on your indirect call:
clazz.indirectPathToA(null);
For even stronger checks the Checker Framework may be a good choice (see this nice tutorial.
Note: I have not used that yet and there may be problems with the Jack compiler: see this bugreport
I agree that the annotations "don't propagate very far". However, I see the mistake on the programmer's side.
I understand the Nonnull
annotation as documentation. The following method expresses that is requires (as a precondition) a non-null argument x
.
public void directPathToA(@Nonnull Integer x){
x.toString(); // do stuff to x
}
The following code snippet then contains a bug. The method calls directPathToA()
without enforcing that y
is non-null (that is, it does not guarantee the precondition of the called method). One possibility is to add a Nonnull
annotation as well to indirectPathToA()
(propagating the precondition). Possibility two is to check for the nullity of y
in indirectPathToA()
and avoid the call to directPathToA()
when y
is null.
public void indirectPathToA(Integer y){
directPathToA(y);
}
@Nonnull
to have indirectPathToA(@Nonnull Integer y)
is IMHO a bad practice: you will need to mainain the propagation on the full call stack (so if you add a null
check in directPathToA()
, you will need to replace @Nonnull
by @Nullable
in the full call stack). This would be a huge maintenance effort for large applications.
If you use Kotlin, it supports these nullability annotations in its compiler and will prevent you from passing a null to a java method that requires a non-null argument. Event though this question was originally targeted at Java, I mention this Kotlin feature because it is specifically targeted at these Java annotation and the question was "Is there a way to make these annotations more strictly enforced and/or propagate further?" and this feature does make these annotation more strictly enforced.
Java class using @NotNull
annotation
public class MyJavaClazz {
public void foo(@NotNull String myString) {
// will result in an NPE if myString is null
myString.hashCode();
}
}
Kotlin class calling Java class and passing null for the argument annotated with @NotNull
class MyKotlinClazz {
fun foo() {
MyJavaClazz().foo(null)
}
}
Kotlin compiler error enforcing the @NotNull
annotation.
Error:(5, 27) Kotlin: Null can not be a value of a non-null type String
see: http://kotlinlang.org/docs/reference/java-interop.html#nullability-annotations
myString.hashCode()
will still be throwing NPE even if @NotNull
is not added in parameter. So whats more specific about adding it?
In Java I'd use Guava's Optional type. Being an actual type you get compiler guarantees about its use. It's easy to bypass it and obtain a NullPointerException
, but at least the signature of the method clearly communicates what it expects as an argument or what it might return.
java.util.Optional
instead of Guava's class. See Guava's notes/comparison for details on the differences.
Since Java 8 new feature Optional you should not use @Nullable or @Notnull in your own code anymore. Take the example below:
public void printValue(@Nullable myValue) {
if (myValue != null) {
System.out.print(myValue);
} else {
System.out.print("I dont have a value");
}
It could be rewritten with:
public void printValue(Optional<String> myValue) {
if (myValue.ifPresent) {
System.out.print(myValue.get());
} else {
System.out.print("I dont have a value");
}
Using an optional forces you to check for null value. In the code above, you can only access the value by calling the get
method.
Another advantage is that the code get more readable. With the addition of Java 9 ifPresentOrElse, the function could even be written as:
public void printValue(Optional<String> myValue) {
myValue.ifPresentOrElse(
v -> System.out.print(v),
() -> System.out.print("I dont have a value"),
)
}
Optional
, there are still many libraries and frameworks that use these annotations such that it is not feasible to update/replace all of your dependencies with versions updated to use Optionals. Optional
can however help in situations where you use null within your own code.
Success story sharing
Optional
type instead of plainnull
Optional
and nullable in this case is thatOptional
better communicates that this value can intentionally be empty. Certainly, it's not a magic wand and in the runtime it may fail exactly the same way as nullable variable. However, API reception by programmer is better withOptional
in my opinion.