La null-safety de Kotlin n’est pas de la magie — c’est un contrat écrit dans le bytecode

Publish date: 8 Jan 2026
Tags: kotlin java-kotlin-interop null-safety

TL;DR #

La null-safety de Kotlin n’est pas une magie de l’IDE : c’est un contrat encodé dans le bytecode¹. Le compilateur publie la nullabilité via @kotlin.Metadata et des annotations @NotNull/@Nullable, que l’IDE lit pour t’avertir²³. Et si du code Java passe quand même null, Kotlin échoue immédiatement à la frontière avec Intrinsics.checkNotNullParameter(...), ce qui évite de propager un état corrompu plus profondément dans ton code.⁴

La null-safety de Kotlin n’est pas de la magie — c’est un contrat écrit dans le bytecode #

Si tu as déjà travaillé dans un codebase mixte Kotlin + Java, tu as probablement rencontré une forme particulière de “magie”. Tu écris soigneusement une classe Kotlin avec des paramètres non-nullables, ce qui garantit l’intégrité interne de l’objet. Puis tu passes dans un fichier Java, tu instancies la classe, et tu tentes de passer null à l’un de ces paramètres supposés “safe”. Immédiatement, ton IDE affiche un avertissement : « Passing ‘null’ argument to parameter annotated as @NotNull »⁵.

À première vue, ça ressemble à de la sorcellerie : comme si l’éditeur regardait au-delà des frontières entre langages pour appliquer des règles qu’il ne devrait pas connaître. Comment l’IDE le sait ? Est-ce juste un “truc” d’éditeur, ou quelque chose de plus profond ? En réalité, Kotlin ne devine rien : il applique un contrat, et ce contrat est écrit noir sur blanc dans le code compilé, visible par tous.

Ce n’est pas qu’un “truc” d’IDE : c’est dans le bytecode #

La null-safety de Kotlin n’est pas seulement une fonctionnalité de syntaxe ou une analyse maligne faite par ton IDE⁶. C’est un contrat concret, encodé dans le bytecode JVM compilé.

En Kotlin, la distinction entre un type non-nullable (String) et un type nullable (String?) est fondamentale.¹ Une variable de type String ne peut jamais contenir null. Ce n’est pas une suggestion : c’est une règle centrale du système de types.

Considère cette classe Kotlin :

class Animal(
    val id: Long,                // non-nullable
    var name: String,           // non-nullable
    var species: String?,       // nullable
    var age: Int? = null,       // nullable avec valeur par défaut
    var nickname: String? = null // nullable

Ici, id et name sont non-nullables : Kotlin garantit qu’ils ne seront jamais null. En revanche, species, age et nickname sont nullables (String?, Int?) : null y est explicitement autorisé.

Quand tu compiles ton code Kotlin, le compilateur s’assure que ce contrat est publié pour que les autres langages JVM puissent le comprendre.³ Il le fait via une approche en deux volets :

Kotlin Metadata : le compilateur ajoute une annotation @kotlin.Metadata au fichier .class.² Elle contient des informations détaillées sur le code Kotlin d’origine, dont la nullabilité réelle des paramètres et propriétés.⁷
Annotations de nullabilité JVM : pour rendre le contrat plus accessible aux outils et frameworks Java standard, le compilateur ajoute aussi des annotations JVM comme @NotNull et @Nullable sur les signatures de méthodes et paramètres de constructeur dans le bytecode.³⁵

C’est comme ça que des outils comme IntelliJ comprennent les règles de nullabilité Kotlin sans jamais parser ton code source Kotlin : ils lisent simplement les annotations et la metadata présentes dans le .class.⁷

Kotlin se défend proactivement à l’exécution #

Que se passe-t-il si un développeur Java ignore l’avertissement de l’IDE et exécute le code malgré tout ? Est-ce que la valeur null passe “entre les mailles du filet” pour provoquer un bug subtil beaucoup plus loin dans la logique de l’objet ? Non. Kotlin joue la défense et protège son contrat à l’exécution.

Regarde cette méthode de notre classe Animal :

*/
    fun speak(sound: String) {
        println("${name} ($species) says: $sound")
    }

Le paramètre sound est non-nullable. Que se passe-t-il si du code Java tente de passer null ?

Le compilateur Kotlin injecte un check au tout début de toute fonction publique (ou constructeur) qui reçoit un paramètre non-nullable.³ Cette défense prend la forme d’un appel statique non négociable, injecté par le compilateur⁴ :

Intrinsics.checkNotNullParameter(parameter, "parameterName")

Si tu passes null depuis Java à un paramètre que Kotlin attend non-nullable, ce check échoue immédiatement. Résultat : une NullPointerException est levée “à l’entrée” du code Kotlin, avant que null n’ait la moindre chance de corrompre l’état interne. Et l’exception contient un message utile indiquant quel paramètre était illégalement null, ce qui rend l’origine du bug très claire.⁶⁴

Voici un test Java qui le montre :

assertEquals("Max", a.getName());
    }

    @Test
    void callingNonNullableParameterWithNullFromJavaThrowsNpe() {
        Animal a = new Animal(3L, "Luna", "Lapin", null, null);

        // speak(sound: String) expects a non-null String in Kotlin.

Au moment exact où a.speak(null) est appelé, le check runtime de Kotlin se déclenche et lève une NullPointerException avec un message clair : "Parameter specified as non-null is null: method Animal.speak, parameter sound".

Tu veux voir la preuve ? Dans IntelliJ ou Android Studio, tu peux vérifier toi-même. Après compilation de ta classe Kotlin, utilise l’action Show Kotlin Bytecode puis clique sur Decompile⁸. Tu verras la représentation Java de ta classe, avec l’annotation @NotNull et l’appel Intrinsics.checkNotNullParameter(...) directement dans le code décompilé.

Si tu es sur Android et que tu actives le shrinking/optimisation (R8/ProGuard), rappelle-toi que tout ce dont tu as besoin à l’exécution (ou via réflexion/outils) doit être protégé avec les bons keep rules.⁹

Par exemple, la version décompilée de speak ressemblerait à ça :

public final void speak(@NotNull String sound) {
   Intrinsics.checkNotNullParameter(sound, "sound");
   String var2 = this.name + " (" + this.species + ") says: " + sound;
   System.out.println(var2);
}

Note l’annotation @NotNull sur le paramètre et l’appel checkNotNullParameter en toute première ligne du corps de la méthode.

Ton IDE est un détective, pas un lecteur de pensée #

Voilà le travail de détective : l’IDE analyse le bytecode et trouve deux indices clés. D’abord, il voit l’annotation @NotNull, le contrat explicite écrit pour les outils Java.³ Ensuite, il sait que du code Kotlin contient un garde-fou runtime — le check Intrinsics — qui fera respecter ce contrat en crashant.⁴ En reliant ces indices, il déduit que ton code va échouer et t’avertit avant même que tu n’appuies sur “run”.

Quand tu écris ce code en Java :

Animal a = new Animal(3L, "Luna", "Lapin", null, null);
a.speak(null);  // ⚠️ IDE warning: "Passing 'null' argument to parameter annotated as @NotNull"

L’IDE signale immédiatement l’appel speak(null), parce qu’il a lu le contrat dans le bytecode et sait que ça va échouer à l’exécution.

IntelliJ ne devine pas : il lit ce que Kotlin a écrit.

Un contrat sur lequel tu peux compter #

La null-safety de Kotlin est un système de défense robuste, à plusieurs couches, qui rend l’interop avec Java plus sûre et plus prédictible. Elle combine : sécurité de compilation via le système de types, annotations bytecode pour l’interop, et checks runtime pour une application stricte. Ce n’est pas une illusion produite par des outils “intelligents” : c’est une architecture tangible, gravée dans le code compilé.

Et la tendance va dans le même sens côté Java : l’écosystème converge aussi vers des contrats de nullness plus explicites (par exemple JSpecify), souvent couplés à de l’analyse statique (ex. NullAway dans des setups Spring).¹⁰¹¹ L’approche est différente, mais l’objectif est le même : faire de “est-ce que ça peut être null ?” un contrat, pas une supposition.

Sachant à quel point Kotlin encode ces contrats de sécurité, qu’est-ce que ça change dans ta façon d’écrire du code à la frontière entre Kotlin et Java ?

Kotlin docs — Null safety (T vs T?), operators, and what the language guarantees (and doesn’t) around null : https://kotlinlang.org/docs/null-safety.html. ↩ ↩
Kotlin stdlib API — kotlin.Metadata annotation reference : https://kotlinlang.org/api/core/kotlin-stdlib/kotlin/-metadata/. ↩ ↩
Kotlin docs — Kotlin↔Java interoperability (cross-calls, annotations, “platform types”, conventions, and pitfalls) : https://kotlinlang.org/docs/java-interop.html. ↩ ↩ ↩ ↩ ↩
JetBrains/Kotlin source — Intrinsics runtime checks (incl. checkNotNullParameter) : https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/jvm/runtime/kotlin/jvm/internal/Intrinsics.java. ↩ ↩ ↩ ↩
IntelliJ IDEA help — Annotating source code (adding/managing annotations like @NotNull/@Nullable) : https://www.jetbrains.com/help/idea/annotating-source-code.html. ↩ ↩
Kotlin docs — Null safety : https://kotlinlang.org/docs/null-safety.html. ↩ ↩
Kotlin docs — Kotlin metadata in .class files and how to consume it on the JVM (inspection/reading via the metadata library) : https://kotlinlang.org/docs/metadata-jvm.html. ↩ ↩
IntelliJ IDEA help — Built-in Java decompiler (viewing decompiled code from bytecode) : https://www.jetbrains.com/help/idea/decompiler.html. ↩
Android Developers — R8/ProGuard optimization and keep rules : https://developer.android.com/topic/performance/app-optimization/add-keep-rules?hl=fr. ↩
JSpecify — User guide (Java nullness annotations and intended usage with tools/compilers) : https://jspecify.dev/docs/user-guide/. ↩
Spring — Null-safety in Spring apps with JSpecify and NullAway : https://spring.io/blog/2025/03/10/null-safety-in-spring-apps-with-jspecify-and-null-away. ↩

Utile ?

Signaler une erreur