La frontera de la nulabilidad

El sistema de tipos de Kotlin sabe distinguir un valor que puede faltar de uno que no puede, y esa distinción es la que sostiene buena parte del lenguaje. El problema es que la JVM no la conoce en absoluto: en el bytecode, una referencia es una referencia, y toda la información sobre si puede valer nulo desaparece en el momento en que el compilador termina su trabajo. Un teorema estático que se evapora al ejecutar no vale nada si alguien puede violarlo desde fuera, y en la JVM siempre hay alguien fuera: código Java, reflexión, deserializadores, generadores de proxies, marcos de trabajo que construyen objetos por vías laterales. La respuesta de Kotlin a ese problema tiene tres capas, y solo entendiéndolas juntas se comprende qué te está garantizando realmente el compilador y dónde termina exactamente esa garantía.

Lo que Kotlin deja escrito

La primera capa es declarativa y va dirigida a las herramientas. Cuando el compilador emite una firma, añade en cada parámetro y en cada retorno de tipo referencia una anotación de nulabilidad del paquete de anotaciones de JetBrains, con la marca de no nulo o la de nulable según corresponda.

fun buscar(clave: String): String? = mapa[clave]

// La firma tal y como la ve un compilador Java
@Nullable
public static final String buscar(@NotNull String clave) { ... }

Esa información no la usa la JVM, que la ignora por completo, sino el compilador de Java y el IDE, que a partir de ella pueden avisar de que estás pasando algo potencialmente nulo o de que deberías comprobar el retorno. Es la mitad amable del contrato: tu código Kotlin le explica a un consumidor Java, en el vocabulario que ese consumidor entiende, qué espera y qué devuelve.

La segunda capa es la ejecutable, y es la que de verdad sostiene la garantía. Sabemos que las anotaciones no obligan a nadie, así que el compilador siembra aserciones baratas exactamente en los puntos donde el sistema de tipos pierde jurisdicción.

Verlo una vez basta para no olvidarlo. Una función tan trivial que parece no tener cuerpo generado resulta empezar por una instrucción que tú no escribiste.

fun saludar(nombre: String) = println("hola $nombre")

public static final void saludar(String nombre) {
    Intrinsics.checkNotNullParameter(nombre, "nombre");
    System.out.println("hola " + nombre);
}

Esa primera línea es la razón de que un nulo procedente de Java produzca una excepción con un mensaje que nombra el parámetro y la función, en lugar de reventar tres capas más abajo con una traza que no señala a nadie. El coste es una comparación contra cero por parámetro, que el compilador de tiempo real elimina en la mayoría de los caminos calientes.

Fíjate en dónde no aparecen. Entre dos funciones privadas del mismo archivo, o en una cadena de llamadas puramente Kotlin dentro de un módulo, el compilador no emite nada: ya lo demostró estáticamente y no hay vía de entrada para un nulo. Las comprobaciones dibujan con precisión quirúrgica el perímetro real de tu módulo, y recorrer el bytecode buscándolas es la forma más directa de ver ese perímetro sobre el papel. Existen banderas para suprimirlas, pero desactivarlas cambia el modo de fallo de excepción con mensaje en la frontera a comportamiento indefinido en el interior, que es precisamente el problema que Kotlin vino a resolver.

Lo que Kotlin lee de fuera

En dirección contraria, el compilador hace lo que puede con la información que encuentre. Si una firma Java no dice nada, produce un tipo de plataforma y te delega la decisión. Si dice algo, deja de inventar y produce tipos Kotlin reales, con verificación estática completa.

Las familias reconocidas son varias y conviene saber que existen porque en un proyecto real te las encontrarás mezcladas: las de JetBrains, las de la vieja especificación JSR-305 con sus valores por defecto a nivel de paquete, las de AndroidX, las de Jakarta, las del Checker Framework, las de Eclipse y, por encima de todas, JSpecify, que es el estándar hacia el que ha convergido el ecosistema.

import org.jspecify.annotations.NullMarked;
import org.jspecify.annotations.Nullable;

@NullMarked
public final class Registro {
    public String obligatorio(String clave) { ... }
    public @Nullable String opcional(String clave) { ... }
    public List<@Nullable String> parciales() { ... }
}

La tercera firma es la razón por la que JSpecify ganó. Las familias antiguas anotaban el contenedor pero no sabían hablar del argumento de tipo, de modo que no podían distinguir una lista no nula de elementos que sí pueden faltar de una lista que puede faltar cuyos elementos nunca son nulos. JSpecify modela la nulabilidad dentro de los genéricos, y Kotlin sabe leerla ahí. Desde Kotlin 2.1 los avisos derivados de JSpecify se tratan como errores por defecto, con lo que una biblioteca Java bien anotada ofrece en Kotlin prácticamente la misma seguridad que el código Kotlin nativo.

Cuando el otro lado miente

Todo lo anterior descansa en que las anotaciones digan la verdad, y no hay nada que lo imponga. Una anotación es un comentario que el compilador de Java opcionalmente vigila; nada impide devolver nulo desde un método marcado como no nulo, y en una base de código grande eso ocurre. La pregunta interesante no es si ocurrirá, sino qué pasa exactamente cuando ocurre.

flowchart TD
J[Java devuelve nulo desde un metodo anotado como no nulo] --> K[Kotlin confio y declaro el tipo como no nulo]
K --> D1[Asignacion directa a variable]
K --> D2[Paso como argumento a funcion publica]
K --> D3[Almacenado en propiedad sin tocar]
D1 --> R1[Fallo inmediato en la linea de la asignacion]
D2 --> R2[Fallo al entrar en la funcion con nombre de parametro]
D3 --> R3[Fallo diferido en el primer uso real y traza enganosa]
style R1 fill:#a6e3a1,color:#11111b
style R2 fill:#a6e3a1,color:#11111b
style R3 fill:#f38ba8,color:#11111b

Los dos primeros caminos son los buenos: la comprobación intrínseca dispara cerca del origen y el mensaje nombra el punto exacto donde alguien incumplió el contrato. El tercero es el patológico, y merece atención porque es el que se ve en producción. Si el valor entra en el sistema y se guarda en una estructura sin que ninguna función pública lo reciba y sin que ninguna afirmación se ejecute, el nulo viaja y estalla mucho después, en un lugar donde el análisis de flujo había concedido acceso directo porque el tipo declaraba que era imposible.

La variante más desconcertante de este patrón no viene de Java escrito a mano sino de la maquinaria. Un deserializador de generación antigua puede construir objetos saltándose el constructor mediante mecanismos de bajo nivel de la máquina virtual y escribir después los campos por reflexión. Así, una propiedad declarada val nombre: String acaba conteniendo nulo sin que ninguna comprobación se haya ejecutado jamás, porque nunca se ejecutó el constructor donde vivía la aserción.

data class Usuario(val nombre: String, val correo: String?)

// Un deserializador no consciente de Kotlin puede producir un Usuario
// con nombre nulo, ignorando el constructor y sus comprobaciones.

La cura no es la desconfianza generalizada, que sería renunciar al sistema de tipos, sino elegir herramientas que lean los metadatos de Kotlin: los serializadores conscientes del lenguaje respetan la nulabilidad declarada, aplican los valores por defecto y fallan al construir con un mensaje que nombra el campo ausente.

La regla operativa que resume el nivel es sencilla y se materializa en muy poco código: la incertidumbre debe concentrarse en una capa fina y auditable de entrada, y todo lo que salga de ella tiene que ser un tipo Kotlin honesto.

// El unico archivo del proyecto que ve tipos de plataforma
private val bruto = RegistroHeredado()

fun buscarClave(clave: String): String? = bruto.buscar(clave)

fun exigirClave(clave: String): String =
    bruto.buscar(clave) ?: error("clave ausente en el registro: $clave")

Una docena de líneas como esas eliminan los tipos de plataforma del resto de la base de código. A partir de ahí, todo lo que circula por el programa son tipos verificados, y las garantías del lenguaje vuelven a aplicarse íntegras sin ninguna comprobación defensiva repartida por el camino.