Pendant près d’une décennie, un petit détail dans la langue turque faisait que le langage de programmation Kotlin – l’un des piliers du développement Android moderne – générait des erreurs apparemment inexplicables. Ce qui a commencé comme un message sur un forum en 2016 a fini par devenir une étape surprenante dans l'histoire du génie logiciel : un langage humain qui a réussi à « casser » un langage de programmation.
Une erreur difficile à comprendre
En mars 2016, l'ingénieur turc Mehmet Nuri Öztürk a publié un message sur le forum Kotlin. Votre code n'a pas été compilé et le compilateur a affiché une erreur énigmatique :
Balise de message du compilateur inconnue : INFO
Personne ne savait ce que cela signifiait. Kotlin venait de sortir la version 1.0, et tout indiquait qu'il s'agissait d'un bug mineur. Cependant, des mois se sont écoulés avant qu'un autre programmeur, Muhammed Demirbaş, soupçonne que le problème n'avait rien à voir avec le code… mais avec le langage du système d'exploitation.
Le « je » turc qui a dérouté le compilateur
Dans la plupart des langues avec l'alphabet latin, la lettre « I » devient « i » lorsqu'elle est convertie en minuscule. Mais en turc, il existe deux variantes de la lettre :
- « i » avec un point → lettre majuscule « İ »
- « ı » sans point → lettre majuscule « I »
Ainsi, alors que « INFO ».toLowerCase() en anglais produit « info », en turc il renvoie « ınfo », avec un Yo ça ne sert à rien. Cette infime différence a empêché le compilateur Kotlin de trouver la catégorie de message attendue et d'échouer avec une erreur incompréhensible.
Le bogue a été officiellement documenté sous le numéro KT-13631 : « La compilation échoue avec les paramètres régionaux turcs en raison de la mise en majuscules sensibles aux paramètres régionaux. » Mais le problème a été enterré parmi des centaines de tickets et n’a pas été résolu. Personne ne se doutait que ce détail allait causer encore plus de dégâts des années plus tard.
Quand les coroutines ont hérité du bug
En 2018, Kotlin a publié la version 1.3 avec l'une de ses fonctionnalités phares : les coroutines, un système permettant de gérer avec élégance les tâches asynchrones. C’est alors que le problème linguistique refait surface avec force.
Le développeur turc Kemal Atlı a signalé une erreur lors de la mise à jour de son application :
java.lang.NoSuchMethodError : Aucune méthode statique boxİnt(I)Ljava/lang/Integer ;
La clé était dans le nom de la méthode : boxİnt()avec un « İ » majuscule et un point. Le compilateur, lors de la génération du code pour les coroutines, a utilisé la fonction capitaliser() pour construire des noms de méthodes comme boîteInt(). Mais lorsqu'il était exécuté sur un système configuré en turc, il convertissait « int » en « İnt » et le compilateur recherchait une méthode qui n'existait pas.
Ce bug particulier a été résolu en 2019 en spécifiant explicitement l'utilisation de la langue anglaise dans l'appel à capitaliser (Locale.US). Mais il était déjà évident que le problème allait bien au-delà d’une simple fonction.
Un troisième bug et la solution définitive
Deux ans plus tard, un autre développeur turc, Muhittin Kaplan, rapportait un nouveau bug : son programme simple avec intArrayOf() échouait avec un NoSuchMethodError. Encore une fois, le coupable était le même : la méthode décapitaliser() avait renvoyé « ıntArray » (avec Yo pas de point) au lieu de « intArray ».
Enfin, la réponse de l'équipe Kotlin a été forte : recherchez et corrigez toutes les opérations de changement de casse dépendant de la langue dans le compilateur. Au total, 173 lignes de code et 53 fichiers ont été modifiés, remplaçant des fonctions toLowerCase(), toUpperCase(), capitalize() et decapitalize() par des versions indépendantes du « locale ».
En mai 2021, avec la sortie de Kotlin 1.5, le bug historique KT-13631 Il a été officiellement fermé, cinq ans après son premier rapport.
Kotlin change son propre langage à cause d'un langage humain
L'impact a été si profond que l'équipe JetBrains a publié la proposition GARDER-223 : »Conversions de casse indépendantes des paramètres régionaux par défaut»pour repenser complètement la façon dont Kotlin gère les conversions de cas.
À partir de Kotlin 1.5, de nouvelles fonctions ont été introduites majuscule() et minuscule()qui ignorent la langue du système. Et depuis Kotlin 2.1 (novembre 2024), l'utilisation de l'ancien toLowerCase() et toUpperCase() génère une erreur de compilation. Même capitaliser() disparu définitivement, remplacé par remplacerPremierChar { … }.
En d’autres termes : la langue turque a obligé la bibliothèque standard Kotlin à changer et à redéfinir les fonctions qui existaient depuis sa naissance.
Plus qu'un bug : une leçon de langue et de culture
En fin de compte, un caractère sans point suffisait à confondre les compilateurs, à faire planter les projets et à forcer les ingénieurs de JetBrains à repenser la manière dont leur langage devait comprendre le texte. Mais le problème ne venait pas de la langue turque ni des programmeurs de Kotlin, mais d'une hypothèse qui s'est avérée injustifiée : selon laquelle « l'alphabet anglais » (la variante anglaise de l'alphabet latin, pour être précis) était la norme universelle en matière d'informatique.
Par | Moyen
