IntelliJ IDEA complains about null check for @NotNull parameter

Question

I want to use Jetbrains @Nullable/@NotNull Annotations in my project.

I have a class with a @NotNull field. The constructor naturally does not accept null but throws an exception instead. Of course the parameter of this constructor is also be annotated with @NotNull.

Why does IntelliJ IDEA complain about the null-check? The documentation states:

An element annotated with NotNull claims null value is forbidden to return (for methods), pass to (parameters) and hold (local variables and fields).

But I still have to check for null-values at runtime in case the build system does not understand the Annotation and accepts a statement like new Car(null). Am I wrong?

Isochor

The build will fail if the annotation doesn't exist, no? In any case, the IDE doesn't have any clue that you don't actually care about the annotation. If you don't want it to complain about the null check disable the inspection. – Typescript

Well that was probably bad wording on my end. I pull the annotation library via gradle. I meant what if the build system does not care about the annotation. – Isochor

Answer 1

If you use JetBrains @NotNull annotation, runtime assertions will be added to your compiled bytecode that'll guarantee that null is not passed there. Then it really makes no sense to write the same checks in the source code. This approach works quite well for us.

If you use other annotations or just don't want to instrument the bytecode, you can disable this particular warning by pressing Alt+Enter on it, "Edit inspection settings" and checking "Ignore assert statements". Such conditional statements are treated as assertions by the IDE.

Effortful

Answer 2

They expect you to use

        Objects.requireNonNull(engine, "engine");

Grandnephew

The downside of that is that it always throws an exception, rather than giving me the option to fail gracefully. – Juarez

Answer 3

If the parameter for the constructor is Not Null, Then there is no point of checking for null value with and if statement.

And As we know that whatever value is held by parameter Engine is not null, this check will always be false.

So the check that is shown in your screenshot will make complete sense. If you really don't want to see the null check inspection, then disable it from the preferences section.

In short, The value you are checking is not null inside the constructor and the IDE is aware of it.

Raconteur

Well I though the annotation is used to inspect the calling code for passing nulls. Just feels wrong to omit the null check and rely on a specific IDE to avoid nulls. – Isochor

I'm just not understanding your point. If you have annotated it as not null, then why would you check for null? It is always not null inside the constructor isn't it? – Raconteur

And this NotNull annotation is from Java 1.6 is same for any IDE. So you do not have to worry – Raconteur

But what if I compile my project on a build server without an IDE? A statement like new Car(null) would compile perfectly fine and will propably lead to obscure NPEs at runtime in completely different code. – Isochor

IDE dependent Annotations are discouraged. Checkout this answer https://mcmap.net/q/18328/-which-notnull-java-annotation-should-i-use There is an Inbuilt java annotation constraint available. – Raconteur

That makes sense, thank you! I will read more on this topic and try to migrate the annotations properly. – Isochor

Just because the parameter is tagged @NotNull doesn't mean that it can never be null. – Juarez

@IanBoyd, If you use JetBrains @NotNull annotation, runtime assertions will be added to your compiled bytecode that'll guarantee that null is not passed there. When the passed parameter is indeed null, then the run time assertion will throw an error even before the if condition in OP's code. – Raconteur

JetBrains does not do runtime assertions. This SO answer says it, and i confirmed it through direct experimental evidence by downloading annotations-23.0.0.jar, annotating a method parameter as @NotNull, and passing a null to the function. The value passed to the method was a null value. In other words: just because a parameter is tagged @NotNull doesn't mean it won't be null. Hence the need to continue to check for null. – Juarez