Le bug silencieux de Gson qui désoriente les développeurs
La prochaine fois que vous nettoierez du code en supprimant une annotation @SerializedName dans une classe de données Kotlin, faites une pause. Ce qui semble être un encombrement superflu pourrait en réalité être l’élément qui maintient ensemble vos réponses d’API. Une analyse approfondie récente du comportement de Gson révèle comment une simple annotation manquante peut transformer discrètement toutes les valeurs baseStat en 0—sans erreur ni avertissement.
Comment Gson fonctionne (et pourquoi c’est trompeur)
Gson ne devine pas où placer les valeurs JSON : il joue à un jeu strict de correspondance exacte des noms. Lorsqu’un serveur envoie une clé comme base_stat, Gson recherche une propriété Kotlin portant exactement le même nom. S’il ne la trouve pas, il laisse le champ à sa valeur par défaut. Pour un Int, cette valeur par défaut est 0. C’est pourquoi la suppression de @SerializedName("base_stat") d’une propriété nommée baseStat ne génère pas d’erreur de compilation—elle fait simplement que Gson ignore le champ.
L’annotation n’est pas décorative : c’est une couche de traduction. Sans elle, Gson considère baseStat et base_stat comme des chaînes sans lien, saute le champ et le remplit avec 0. La solution ? Soit renommer la propriété en base_stat (ce qui enfreint les conventions Kotlin), soit rétablir l’annotation @SerializedName. Cette dernière option préserve la propreté du code tout en maintenant le lien entre JSON et Kotlin.
La philosophie derrière le silence de Gson
Ce qui surprend le plus n’est pas le bug lui-même, mais le silence de Gson. Une clé manquante ne déclenche pas d’erreur—elle est traitée comme un champ de formulaire vide. Gson construit votre objet, remplit ce qu’il peut, et laisse le reste à ses valeurs par défaut : 0 pour les nombres, null pour les objets et false pour les booléens. Seuls un JSON mal formé ou des incompatibilités de type (comme une chaîne à la place d’un nombre) feront lever une exception.
Ce choix de conception est intentionnel mais risqué. Il privilégie la résilience à la rigueur, en accord avec l’objectif de Gson de parser ce que le serveur envoie. Pourtant, cela entre en conflit avec les garanties de null-safety de Kotlin. Une String non nulle en Kotlin peut finir par être null si le champ JSON est absent—sapeant ainsi la promesse centrale du langage.
Enseignements pour les développeurs
La leçon est simple : la flexibilité de Gson est une arme à double tranchant. Si elle gère élégamment les données imparfaites, ce silence peut masquer des problèmes critiques. Vérifiez toujours les annotations @SerializedName lors d’une refonte, et envisagez d’ajouter des couches de validation pour détecter les incohérences tôt. Pour les équipes, ce bug constitue une excellente question d’entretien—car il évalue la compréhension de la sérialisation, des conventions de nommage et des contrats cachés entre le code et les API.
Source : DEV Community. Synthèse éditoriale assistée par IA — TechnoExpress.