Nullness annotations and injected parameters

We recently ran into a NullPointerException although we make heavy use of static null analysis with the corresponding annotations. We are using NonNullByDefault which means any method or constructor parameter is considered non-null. If it’s being used in the analyzed code with a null parameter the compiler will raise an error. However in this particular case it was a constructor that is used for JSON deserialization with Jackson. In these cases you simply cannot guarantee that a value is non-null. However, the static analysis is unable to detect it because the constructor is called outside of its scope and via reflection. Therefore I’m proposing a new rule that raises whenever a parameter is annotated to be non-null and it has a common injection annotation, such as JsonProperty as well.
Non-compliant example:

@org.eclipse.jdt.annotation.NonNullByDefault
public class NonCompliant {
    public NonCompliant(@com.fasterxml.jackson.annotation.JsonProperty("bar") String bar) {
        bar.length(); // this can fail at runtime
    }
}

Compliant example:

@org.eclipse.jdt.annotation.NonNullByDefault
public class Compliant {
    public Compliant(@org.eclipse.jdt.annotation.Nullable @com.fasterxml.jackson.annotation.JsonProperty("bar") String bar) {
        bar.length(); // will raise a compiler error
    }
}

Hello @sithmein

Thanks for the suggestion, I understand the situation, and it makes sense to me.

My only concern at this point is that it is about a specific behavior of Jackson. Covering this framework is on our radar, we will therefore eventually come back to this idea, but I can already tell you that it will not be in the near future.

One idea to push this rule forward could be to make it more general and target more globally the concept of annotation implicitly changing the nullability value, but this would require more investigation, and I’m not even sure it makes sense.

In the meantime, you can always consider implementing it as a custom rule, the implementation should be rather simple.

Hope it clarifies the situation.

Best,
Quentin