Which @NotNull in Java to Choose? Diving Under the Hood

The Curse of NullPointerException: Choosing the Right @NotNull

If you've ever written Java, you've certainly encountered NullPointerException (NPE). This is perhaps the most common error that breaks production. Developers have come up with an elegant way to combat it — the @NotNull and @Nullable annotations. But here's the catch: the Java world has at least a dozen different implementations of this annotation from various vendors. Which one to choose? Why are there so many? And what happens "under the hood" when you add @NotNull?

On Stack Overflow, the question "Which @NotNull Java annotation should I use?" has gathered thousands of views and hundreds of votes. This is a real headache for both beginners and pros. In this article, we'll break down all the main options, show real code, and give you a clear action plan. Let's go!

Why Do We Even Need @NotNull Annotations?

Java is a statically typed language, but it cannot distinguish between null and non-null references at the type level (unlike Kotlin or Rust). Annotations are metadata that tell the compiler, IDE, or static analyzer: "Hey, look, this field should never be null!".

Using @NotNull provides three key benefits:

\n
• Early error detection — the IDE will highlight a potential NPE even before runtime.
\n
• Code documentation — developers immediately see the method contract.
\n
• Integration with tools — Lombok, Checker Framework, FindBugs, and others use these annotations for code generation and checks.
\n

The problem is that every major ecosystem (JetBrains, Google, Eclipse, Oracle) has created its own version. Let's go through them in order.

Main Candidates: Who's Who

1. javax.annotation.Nonnull (FindBugs / JSR-305)

This was the first "de facto standard". An annotation from the javax.annotation package (JSR-305).

import javax.annotation.Nonnull;\n\npublic class UserService {\n    public String greet(@Nonnull String name) {\n        return "Hello, " + name;\n    }\n}

Pros: historically popular, supported by older tools (FindBugs, IntelliJ IDEA with plugin).
\nCons: JSR-305 got stuck in "draft" status and never became part of Java SE. The com.google.code.findbugs:jsr305 library hasn't been updated in a long time. Not recommended for new projects.

2. jakarta.annotation.Nonnull (Jakarta EE)

After Java EE moved to the Eclipse Foundation, the javax.* package was renamed to jakarta.*. The jakarta.annotation.Nonnull annotation is the modern successor.

import jakarta.annotation.Nonnull;\n\npublic class RestController {\n    public void process(@Nonnull String data) {\n        // data is guaranteed not null\n    }\n}

Pros: officially supported, part of Jakarta EE 9+, has a chance of standardization.
\nCons: requires adding the jakarta.annotation-api dependency. Not all analysis tools have been updated.

3. org.jetbrains.annotations.NotNull (IntelliJ IDEA)

The most popular annotation among IntelliJ users. Distributed in the org.jetbrains:annotations library.

import org.jetbrains.annotations.NotNull;\n\npublic class DataValidator {\n    public boolean validate(@NotNull String input) {\n        return input.length() > 3;\n    }\n}

Pros: excellent integration with IntelliJ IDEA (highlighting, inspections, auto-generation of checks). Lightweight dependency (only 26 KB).
\nCons: tied to JetBrains IDE. If the team uses Eclipse or VS Code — less effective.

4.