¿Qué @NotNull elegir en Java? Analizando bajo el capó

La maldición de NullPointerException: eligiendo la @NotNull correcta

Si alguna vez has programado en Java, seguramente te has encontrado con NullPointerException (NPE). Este es, probablemente, el error más común que afecta a producción. Los desarrolladores idearon una forma elegante de combatirlo: las anotaciones @NotNull y @Nullable. Pero aquí está el problema: en el mundo de Java existen al menos una docena de implementaciones diferentes de esta anotación de distintos proveedores. ¿Cuál elegir? ¿Por qué hay tantas? ¿Y qué sucede «bajo el capó» cuando colocas @NotNull?

En Stack Overflow, la pregunta "Which @NotNull Java annotation should I use?" ha acumulado miles de visitas y cientos de votos. Es un verdadero dolor de cabeza tanto para novatos como para profesionales. En este artículo, desglosaremos todas las opciones principales, mostraremos código real y daremos un plan de acción claro. ¡Allá vamos!

¿Para qué sirven las anotaciones @NotNull?

Java es un lenguaje de tipado estático, pero no puede distinguir entre referencias null y no-null a nivel de tipos (a diferencia de Kotlin o Rust). Las anotaciones son metadatos que le indican al compilador, IDE o analizador estático: «¡Oye, mira, este campo nunca debe ser null!».

El uso de @NotNull proporciona tres ventajas clave:

\n
• Detección temprana de errores — el IDE resaltará un posible NPE incluso antes de ejecutar.
\n
• Documentación del código — el desarrollador ve inmediatamente el contrato del método.
\n
• Integración con herramientas — Lombok, Checker Framework, FindBugs y otras utilizan estas anotaciones para generación de código y verificaciones.
\n

El problema es que cada ecosistema importante (JetBrains, Google, Eclipse, Oracle) creó su propia versión. Vamos a analizarlas en orden.

Principales candidatos: quién es quién

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

Este fue el primer «estándar de facto». Anotación del paquete javax.annotation (JSR-305).

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

Ventajas: históricamente popular, compatible con herramientas antiguas (FindBugs, IntelliJ IDEA con plugin).
\nDesventajas: JSR-305 quedó en estado «borrador» y nunca formó parte de Java SE. La biblioteca com.google.code.findbugs:jsr305 no se actualiza desde hace tiempo. No recomendada para proyectos nuevos.

2. jakarta.annotation.Nonnull (Jakarta EE)

Después de la transición de Java EE a Eclipse Foundation, el paquete javax.* fue renombrado a jakarta.*. La anotación jakarta.annotation.Nonnull es la heredera moderna.

import jakarta.annotation.Nonnull;\n\npublic class RestController {\n    public void process(@Nonnull String data) {\n        // data garantizadamente no es null\n    }\n}

Ventajas: compatible oficialmente, parte de Jakarta EE 9+, tiene posibilidades de estandarización.
\nDesventajas: requiere agregar la dependencia jakarta.annotation-api. No todas las herramientas de análisis se han actualizado.

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

La anotación más popular entre los usuarios de IntelliJ. Se distribuye en la biblioteca org.jetbrains:annotations.

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

Ventajas: excelente integración con IntelliJ IDEA (resaltado, inspecciones, generación automática de verificaciones). Dependencia ligera (solo 26 KB).
\nDesventajas: vinculación al IDE de JetBrains. Si el equipo usa Eclipse o VS Code, el efecto es menor.

4.