How to use Nullable and Nonnull annotations more effectively

Question

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

What I do in my projects is to activate the following option in the  Constant conditions  amp  exceptions  code inspection  Suggest  Nullable annotation for methods that may possibly return null and report nullable values passed to non-annotated parameters   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

User · Answer

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

User · Answer

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

User · Answer

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 lt String gt  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 lt String gt  myValue        myValue ifPresentOrElse          v - gt  System out print v              - gt  System out print  I dont have a value

User · Answer

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

[java] How to use @Nullable and @Nonnull annotations more effectively?

Examples related to java

Examples related to annotations

Examples related to nullpointerexception

Examples related to nullable

Examples related to code-standards