184

I can see that @Nullable and @Nonnull annotations could be helpful in preventing NullPointerExceptions 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?

Improve this question
12
  • 1
    I like the idea of @Nullable or @Nonnull, but if they are worth it is very "likely to solicit debate" Commented Nov 20, 2012 at 23:59
  • 2
    @TheodoreMurdock, yes, in Java 8 a cast (@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). Commented Sep 18, 2015 at 22:13
  • 3
    It would be helpful in this question to say which @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? Commented Feb 2, 2017 at 15:46
  • 2
    @TJamesBoone For the context of this question it does not matter, this was about how to use any of them effectively. Commented Feb 6, 2017 at 17:42
  • 1
    @WilliamEntriken If you have the option, you can mix Kotlin in with Java. Kotlin is very interoperable with Java and has a lot of the niceties you expect in Swift... also solves this problem stackoverflow.com/a/46290602/444639 Commented Aug 15, 2019 at 19:02

11 Answers 11

Reset to default
94

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 value and use Null Object Pattern instead.

Improve this answer
Sign up to request clarification or add additional context in comments.

9 Comments

For return values possibly being empty, I strongly suggest using the Optional type instead of plain null
Optional ist not better, than "null". Optional#get() throws NoSuchElementException while a usage of the null throws NullPointerException. Both are RuntimeException's without meaningful description. I prefer nullable variables.
@30thh why would you use Optional.get() directly and not Optional.isPresent() or Optional.map first?
@GauravJ Why would you use a nullable variable directly and not check, if it null first? ;-)
The difference between Optional and nullable in this case is that Optional 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 with Optional in my opinion.
|
43

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:

This can help your code be more maintainable (since you do not need null checks) and less error-prone.

Improve this answer

4 Comments

I sympathize with the OP here, because even though you cite these two advantages, in both cases you used the word "can." That means that there is no guarantee that these checks will actually occur. Now, that behavioral difference could be useful for performance-sensitive tests that you'd like to avoid running in production mode, for which we have 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.
The question is where to begin. At the moment his anntations are optional. Somtimes I would like it if they were not because in some circumstances it would be helpful to enforce them...
May I ask what is AOP you're referring here?
@Chris.Zou AOP means aspect oriented programming, e.g. AspectJ
18

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:

Java 8's new Type Annotations

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.

Improve this answer

2 Comments

Understood, but the default lint checks warn that runtime null checks are unnecessary, which at first impression seems to discourage this recommendation.
@swooby Usually I ignore lint warnings if I’m sure my code is correct. Those warnings are not errors.
13

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.

Improve this answer

Comments

9

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. Even 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: https://kotlinlang.org/docs/java-interop.html#nullability-annotations

Improve this answer

5 Comments

The question addresses Java, per its first tag, and not Kotlin.
@seh see update for why this answer is relevant to this question.
Fair enough. That's a nice feature of Kotlin. I just don't think it's going to satisfy those coming here to learn about Java.
but accessing myString.hashCode() will still be throwing NPE even if @NotNull is not added in parameter. So whats more specific about adding it?
@kAmol The difference here is that when using Kotlin, you will get a compile time error instead of a runtime error. The annotation is to notify that you the developer need to ensure that a null is not passed in. This will not prevent a null from being passed in at runtime, but it will prevent you from writing code that calls this method with a null (or with a function that can return null).
8

What I do in my projects is to activate the following option in the "Constant conditions & exceptions" code inspection:
Suggest @Nullable annotation for methods that may possibly return null and report nullable values passed to non-annotated parameters Inspections

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

Improve this answer

1 Comment

This is so much cleaner!
7

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); }
Improve this answer

3 Comments

Propagating the @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 @Nonnullby @Nullable in the full call stack). This would be a huge maintenance effort for large applications.
@Nonnull annotation just emphasises that null-verification of the argument is on your side (you have to guarantee that you pass non-null value). It is not the responsibility of the method.
@Nonnull is also sensible thing when null-value do not make any sense for this method
4

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.

Improve this answer

3 Comments

You have to be careful with this. Optional should only be used where a value is truly optional, and the absence of which is used as a decision gate for further logic. I've seen this abused with blanket replacement of Objects with Optionals and null checks replaced with checks for presence which misses the point.
if you are targeting JDK 8 or newer, prefer to use java.util.Optional instead of Guava's class. See Guava's notes/comparison for details on the differences.
"null checks replaced with checks for presence which misses the point" can you elaborate, then, on what the point is? This isn't the only reason for Optionals, in my opinion, but it's certainly by far the largest and best one.
0

@NotNull from javax.validation.constraints means that the method never returns a null value.. ;) So, that means on getting any value from that method, you need not add any null check for checking for null pointer exceptions.. :D

Improve this answer

Comments

0

A very old question, but I don't see anybody pointing out that to get a check on execution time you should use assertions.

Like this

assert x != null;

This will work (throw an exception) no matter the level of indirection

Improve this answer

2 Comments

This is true, but an NPE would already be thrown... The answer I eventually went with is to use Kotlin wherever possible and then get this as a compile time check. See: stackoverflow.com/a/46290602/444639
Nullness annotations allow to perform compile-time checks which are much preferable when possible compared to run-time checks (so that errors could be fixed as early as development instead of releasing a patch). Moreover, asserts are checked only if VM was launched with -ea parameter
-7

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"), ) }
Improve this answer

2 Comments

Even with 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.
Annotations still have some advantages that may make them preferable compared to Optional : they don't impact performance (no need to instantiate many Optional objects), they work better with generics (one can define T extends @Nullable Object, then return <T> could either yield return @NonNull Object or return @Nullable Object whereas return Optional<T> will always require a non-empty check even in cases where the type parameter is known not to be nullable), and one can even attach these annotations to external libraries that haven't been designed with nullness-aware API

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.