O Bug Invisível: Como um Erro 404 Me Ensinou a Olhar Para os Detalhes

Sabe quando você começa um projeto cheio de confiança, com o plano todo desenhado na cabeça? Era exatamente assim que eu estava quando decidi criar uma API de pagamentos com Java e Spring Boot para o meu portfólio. A ideia era simples: montar uma aplicação robusta, seguindo as boas práticas, para mostrar do que sou capaz. Mal sabia eu que estava prestes a embarcar numa saga de depuração que testaria minha paciência e me ensinaria mais do que qualquer tutorial.

Tudo começou bem. Fui no start.spring.io, peguei as dependências de sempre — Spring Web, JPA, H2, Lombok — e comecei a montar a estrutura do meu primeiro microsserviço, o de usuários. Criei os pacotes bonitinho, separando controllers, services, repositories, tudo como manda o figurino. Modelei a entidade User, o repositório, o serviço com as regras de negócio… até aí, tudo tranquilo, o tipo de trabalho que a gente faz no piloto automático.

O primeiro sinal de que as coisas não seriam tão simples veio quando tentei simular um ambiente Oracle, algo que vejo muito em vagas de emprego. Configurei o H2 para rodar em modo de compatibilidade e ajustei o dialeto do Hibernate. Quase que imediatamente, o console cuspiu o primeiro erro: “Table ALL_SEQUENCES not found”. Clássico. O Hibernate, tentando ser fiel ao Oracle, procurou por uma tabela de sistema que o H2, coitado, não tinha. Depois de algumas tentativas, a solução veio num ajuste fino no application.properties, mandando o Hibernate usar o dialeto do H2, mesmo com o banco em modo Oracle. “Ok”, pensei, “primeiro desafio superado, faz parte”.

Mas a alegria durou pouco. Com a aplicação finalmente subindo sem nenhum erro vermelho no log, eu me deparei com um fantasma: um erro 404 teimoso em toda e qualquer chamada para a API. O log de startup era uma maravilha, dizia que o Tomcat estava no ar, que a aplicação tinha iniciado com sucesso. Mas na prática, era como se meus controllers fossem invisíveis. E aí começou a verdadeira caça ao bug.

Primeiro, a suspeita óbvia: a estrutura de pacotes. Será que coloquei a classe principal no lugar errado e o Spring não está achando meus componentes? Fui lá, chequei, e não, estava tudo perfeito. Depois, revisei o código do controller e do service umas dez vezes, procurando erros de digitação, imports errados, qualquer coisinha. Corrigi uns detalhes, mas nada. O 404 continuava lá, rindo da minha cara.

A frustração começou a bater forte. Como pode a aplicação dizer que está tudo bem, mas não funcionar? Foi aí que, olhando o log de startup pela vigésima vez, notei um detalhe que tinha ignorado: a aplicação estava rodando com Java 24, mas meu projeto estava configurado no pom.xml para o Java 17. Bingo! Uma incompatibilidade silenciosa. O tipo de problema que não quebra a aplicação, mas a deixa num estado “zumbi”.

A solução parecia clara: alinhar as versões do Java. Decidi seguir o caminho profissional e usar o SDKMAN! para gerenciar as versões. E claro, nada é fácil. Para instalar o SDKMAN!, precisei primeiro instalar o unzip e o zip, e para isso, tive que consertar a lista de servidores do meu gerenciador de pacotes. Uma saga dentro da saga. Mas, enfim, consegui. Ambiente configurado com Java 17, projeto reconstruído, tudo certo. E quando rodei a aplicação... o mesmo 404.

Nesse ponto, a vontade era de fechar o notebook e ir dormir. O que mais poderia ser? O código estava certo, o ambiente estava certo, o log estava limpo. Foi aí que, num último ato de desespero, comecei a olhar não o conteúdo dos arquivos, mas os próprios arquivos. E então eu vi. O erro mais bobo e mais invisível de todos. A extensão dos meus arquivos não era .java. Era .Java, com "J" maiúsculo. Meu sistema operacional diferenciava os dois, e para o compilador do Java, era como se aquelas classes simplesmente não existissem.

Corrigi a extensão, rodei a aplicação, e quando o curl retornou aquele [] na tela, o alívio foi imenso. Essa jornada foi um lembrete doloroso, mas valioso, de que no nosso mundo, os maiores problemas às vezes se escondem nos detalhes mais insignificantes. E que, no fim das contas, a persistência é a nossa ferramenta de depuração mais poderosa.