Page index des articles liés à la JVM et à Kotlin. Regroupe tutoriels, patterns et retours d’expérience.
Cible : développeurs JVM cherchant solutions pratiques, exemples de code et guides d’architecture.
Derniers articles
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 →
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.
Lire la suite →
Articles plus anciens 5
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 →
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 →
Inspiré de la conf vJUG CONNECT “AI & Java: From Structured Prompts to Smarter Apps” (YouTube).
TL;DR
#
Si tu retiens une seule idée : le “prompt engineering” n’est pas le sujet. Le sujet, c’est l’ingénierie du contexte et du contrat entre ton code et le modèle :
- mémoire (court/long terme, cohérence, conflits),
- outils (fonctions appelables par le LLM),
- sorties structurées (JSON/records/enums au lieu de texte libre),
- observabilité + timeouts + fallbacks (parce que “ça marche en démo” ne vaut rien en prod).
La conf le dit sans détour : ce n’est pas de la magie, c’est du logiciel.
Lire la suite →
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 →
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 :
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 →