Kotlin

Kotlin 2.3 : 5 nouveautés vraiment utiles (et quoi activer tout de suite)

Kotlin 2.3.0 est une release de maturité : moins de “features tape-à-l’œil”, plus de garde-fous, de DX et de perf. Elle ne “change pas votre façon de coder” par magie — mais elle vous évite des classes entières de bugs et réduit du boilerplate si vous activez les bons interrupteurs. :contentReference[oaicite:0]{index=0}

TL;DR #

  • Détecter les valeurs de retour ignorées (opt-in) → moins de bugs silencieux. :contentReference[oaicite:1]{index=1}
  • Explicit backing fields (expérimental) → fin du duo _state / state et smart-cast sur field. :contentReference[oaicite:2]{index=2}
  • UUID v7 + parseOrNull (API UUID expérimentale) → IDs triables temporellement, parsing sans exceptions. :contentReference[oaicite:3]{index=3}
  • Kotlin/Native + Swift export → enums et vararg plus naturels côté Swift + builds release jusqu’à ~40% plus rapides. :contentReference[oaicite:4]{index=4}
  • Kotlin/Wasm → binaires jusqu’à ~13% plus légers + KClass.qualifiedName activé par défaut, grâce au stockage compact Latin-1. :contentReference[oaicite:5]{index=5}

Lire la suite →

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 bytecode1. Le compilateur publie la nullabilité via @kotlin.Metadata et des annotations @NotNull/@Nullable, que l’IDE lit pour t’avertir23. 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.4

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 →

NoClassDefFoundError: jakarta/servlet/Filter (root cause + fix)

TL;DR (répare en 60 secondes) #

Si tu vois :

  • ** WARNING ** : Your ApplicationContext is unlikely to start due to a @ComponentScan of the default package.
  • puis NoClassDefFoundError: jakarta/servlet/Filter

➡️ Verdict : ta classe @SpringBootApplication est dans le default package (pas de package ...).
➡️ Fix : déclare un vrai package + place le fichier dans le dossier qui correspond (et aligne tes tests).

Lire la suite →

Sérialiser les sealed classes Kotlin avec Jackson : causes, solutions, arbitrages

Pour qui / Quand / Résultat / Commande

  • Pour qui : Développeurs Kotlin/JVM (Spring Boot, Ktor, etc.) confrontés à des erreurs de (dé)sérialisation de sealed classes avec Jackson.
  • Quand : Dès qu’une sealed class ou hiérarchie polymorphe doit être (dé)sérialisée en JSON côté API ou persistence.
  • Résultat : Comprendre pourquoi ça casse, appliquer un fix rapide, arbitrer une refacto si besoin, valider par des tests reproductibles.
  • Commande :
./gradlew test

TL;DR #

Jackson ne gère pas nativement la (dé)sérialisation polymorphe des sealed classes Kotlin. Sans configuration adaptée, la désérialisation échoue ou perd le sous-type. Ce guide explique pourquoi, comment le reproduire, et propose des solutions rapides (module Kotlin, annotations, registration manuelle) ainsi qu’une alternative architecturale (séparer DTO/domain). Tests fournis pour valider chaque approche.

Lire la suite →