Null-Safety

4 révélations qui vont transformer votre approche de la null-safety en Java (JSpecify + NullAway)

TL;DR #

JSpecify 1.0.0 met fin à la tour de Babel des @Nullable en standardisant 4 annotations stables.
@NullMarked inverse le défaut : non-null par défaut, @Nullable devient l’exception visible.
IDE et CI convergent : IntelliJ et NullAway se sont alignés (notamment sur les suppressions).
TYPE_USE rend la nullité “chirurgicale” (tableaux, génériques), mais il faut apprendre la grammaire.

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

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.⁴

Lire la suite →

Kotlin ↔ Java : la null-safety, c’est un contrat (et comment Kotlin le fait respecter)

TL;DR #

En interop Kotlin ↔ Java, la null-safety n’est pas magique :

Kotlin→Java : le compilateur publie la nullabilité dans le bytecode (annotations @NotNull/@Nullable + @kotlin.Metadata), donc l’IDE voit le contrat.
Java→Kotlin : si Java passe quand même null là où Kotlin exige non-null, Kotlin fail-fast à la frontière via Intrinsics.checkNotNullParameter(...).
Le vrai point faible : quand Kotlin consomme des API Java non annotées → types “platform” (String!) = nullabilité inconnue → c’est là que les bugs se glissent.

Lire la suite →