--- title: "O Bug que Levou 5 Anos: Como o Alfabeto Turco Quebrou a Linguagem de Programação Kotlin" author: "Ignácio Afonso" date: "2025-10-17 16:03:00-03" category: "Segurança & Privacidade" url: "http://desbugados.scale.press/portal/desbugados/post/2025/10/17/o-bug-que-levou-5-anos-como-o-alfabeto-turco-quebrou-a-linguagem-de-programacao-kotlin/md" --- ## O Mistério do Compilador Silencioso Tudo começou em março de 2016, apenas um mês após o lançamento do Kotlin 1.0. Um desenvolvedor turco, Mehmet Nuri Öztürk, postou em um fórum de discussão sobre um erro enigmático que o impedia de compilar seu código. A mensagem era curta e grossa: Error:Kotlin: Unknown compiler message tag: INFO. Não havia pistas, e o problema persistia em diferentes máquinas e sistemas operacionais. Era como um fantasma na máquina, e a equipe do Kotlin, na época, ficou sem respostas claras. A primeira grande descoberta veio cinco meses depois, graças a outro programador da Turquia, Muhammed Demirbaş. Investigando o mesmo problema, ele suspeitou que a causa poderia estar ligada ao seu idioma e localidade. Em sua análise, citada no fórum, ele foi cirúrgico: “Aparentemente, este é um problema de maiúsculas e minúsculas com o 'I' turco no mapa CompilerOutputParser.CATEGORIES”. Muhammed estava absolutamente correto. Ele descobriu que o compilador do Kotlin lia tags de mensagens em XML, como , e as convertia para minúsculas usando a função toLowerCase() antes de procurar a correspondência em um mapa de categorias com chaves como "info" e "error". Aqui reside o cerne do problema, uma peculiaridade linguística que se tornou uma falha de software. Em inglês, "INFO".toLowerCase() resulta em "info". Simples. No entanto, em turco, o resultado é "ınfo", com um "ı" sem pingo. Isso ocorre porque o idioma turco possui duas versões da letra 'i': uma com pingo (i/İ) e outra sem pingo (ı/I). Para um computador, "info" e "ınfo" são strings completamente diferentes. O resultado? O compilador não encontrava a correspondência, gerando o erro misterioso. A equipe do Kotlin abriu um ticket no seu rastreador de bugs, o KT-13631, mas com poucos usuários afetados, o problema ficou na geladeira. Mal sabiam eles que o bug estava apenas hibernando. ## Coroutines: O Bug Sobe de Nível Avançamos para outubro de 2018. O Kotlin 1.3 é lançado, trazendo a versão estável das aguardadas coroutines, uma ferramenta poderosa para programação assíncrona. Desenvolvedores em todo o mundo começaram a atualizar seus projetos, e foi então que o bug decidiu evoluir. Relatos de um novo erro começaram a surgir, novamente vindos da comunidade turca. Desta vez, era um java.lang.NoSuchMethodError, um erro que geralmente aponta para conflitos de versão entre bibliotecas. O desenvolvedor Kemal Atlı foi um dos primeiros a reportar o problema em um issue no GitHub. A mensagem de erro continha uma pista sutil, quase invisível: No static method boxİnt(I)Ljava/lang/Integer;. A princípio, todos, incluindo os mantenedores da biblioteca, acreditaram ser um caso clássico de cache de build sujo ou uma dependência incompatível. A recomendação padrão era “limpe o build e reinicie a IDE”. Mas o erro persistia. Foi só em dezembro daquele ano que Erel Özçakırlar, outro engenheiro turco, conectou os pontos. Ele notou o que ninguém havia visto: a função no erro era boxİnt(), com um 'İ' maiúsculo e com pingo, enquanto a função correta deveria ser boxInt(). O compilador não estava procurando uma função antiga; ele estava, efetivamente, inventando um nome de função que nunca existiu. O culpado? A função capitalize(). Para otimizar as coroutines, o compilador do Kotlin gera chamadas para funções auxiliares como boxInt(), boxBoolean(), etc. Ele construía esses nomes dinamicamente, pegando o nome do tipo primitivo (como "int") e aplicando capitalize(). Em uma máquina configurada com o locale turco, "int".capitalize() resulta em "İnt". O compilador, então, gerava código que tentava chamar uma função inexistente chamada boxİnt(). Oops! ## A Caçada Final e a Grande Reforma Com essa descoberta, a equipe do Kotlin finalmente tinha um caminho claro. Em setembro de 2019, Fatih Doğan criou um repositório no GitHub com um exemplo que reproduzia o erro de forma consistente, o que foi determinante para a solução. A correção, lançada no Kotlin 1.3.6, foi simples: forçar o uso do locale americano ao chamar a função, assim: capitalize(Locale.US). O bug das coroutines estava morto. Mas a raiz do problema continuava viva. A prova disso veio em setembro de 2020, quando Muhittin Kaplan, um iniciante em Kotlin, se deparou com um NoSuchMethodError ao usar uma das funções mais básicas da linguagem: intArrayOf(). Desta vez, o culpado era a função decapitalize(). O compilador, ao processar o tipo IntArray, aplicava a função para obter o nome da função intrínseca correspondente. Em turco, "IntArray".decapitalize() se tornava "ıntArray", com o 'ı' sem pingo, causando a falha em tempo de execução. Este foi o estopim. A equipe da JetBrains percebeu que correções pontuais não seriam suficientes. Era preciso uma varredura completa. Eles caçaram todas as chamadas de funções de conversão de caso (toLowerCase(), toUpperCase(), capitalize(), decapitalize()) no código-fonte do compilador e as substituíram por alternativas que não dependem do locale do sistema. De acordo com os registros do commit, a operação resultou em 173 linhas de código alteradas em 53 arquivos. Em maio de 2021, com o lançamento do Kotlin 1.5, a correção massiva foi ao ar, e o ticket original, KT-13631, foi finalmente fechado. Cinco anos depois. ## Uma Lição Escrita em Código (e em Turco) A saga do bug turco ensinou uma lição fundamental para a equipe do Kotlin e para a comunidade de desenvolvimento em geral: código de sistema, como um compilador, nunca deve depender das configurações de ambiente do usuário. Para solidificar essa lição, a proposta KEEP-223 foi aprovada, introduzindo novas funções de conversão de caso, como uppercase() e lowercase(), que são agnósticas ao locale por padrão. As funções antigas foram marcadas como obsoletas, e a ambígua capitalize() foi removida por completo nas versões mais recentes. Esta história é um belo exemplo de como a programação não é apenas lógica e matemática. Ela é profundamente entrelaçada com a cultura e a linguagem humana, com todas as suas complexidades e exceções. É um lembrete, como diria um velho arqueólogo digital, que até os sistemas mais robustos podem ser derrubados por algo tão pequeno e humano quanto o pingo de um 'i'. Afinal, como diz aquela piada sem graça, por que o programador turco ficou triste? Porque seu código não tinha pingo de compaixão.