Tecnologia
Você subiu o servidor MCP, expôs as tools direitinho, testou com o inspector e estava tudo lá. Aí foi plugar o seu app Java como cliente e nada. O listTools() volta uma lista vazia, ou pior, a chamada fica pendurada até estourar o timeout. Você revisa o servidor, revisa de novo, e o servidor está certo. O problema está do lado do cliente, e quase sempre tem nome: transporte errado.
Esse é o erro número 1 de quem escreve um cliente MCP em Java hoje. Usar o SSE legado contra um servidor que fala Streamable HTTP, ou chamar listTools() antes do initialize(). A conexão até abre, mas nenhuma capability é negociada, e tool nenhuma aparece. Bora resolver isso de vez, com o código certo para cada caso, usando o MCP Java SDK 2.0 que saiu como GA em junho.
- Detalhes
- Escrito por: Jorge Demetrio
- Categoria Pai: Linguagem de programação
- Categoria: Java
-
Também disponível:
- Acessos: 166
Tem uma flag que metade dos pipelines de CI carrega há anos sem ninguém lembrar por quê: -noverify. Alguém colocou lá em 2017 pra "acelerar o startup" pulando a verificação de bytecode, o build ficou verde, e ninguém mais tocou. Até o dia em que você troca a imagem base pra eclipse-temurin:27 e o container simplesmente não sobe. Nos logs, uma linha seca: Unrecognized option: -noverify.
O JDK 27 parou de ser tolerante com quatro opções antigas de launcher: -noverify, -Xverify:none, -noclassgc e -verifyremote. Elas estavam depreciadas (com aviso) desde o Java 13, e agora viraram erro fatal: a JVM nem inicia. Se alguma sobreviveu num Dockerfile, num argLine do Surefire ou numa run config de IDE, o build vai parar de subir bem na hora do upgrade. Bora ver onde isso se esconde, como varrer o projeto antes e como arrumar direito.
- Detalhes
- Escrito por: Jorge Demetrio
- Categoria Pai: Linguagem de programação
- Categoria: Java
-
Também disponível:
- Acessos: 131
Imagina a cena: você só trocou a tag da imagem Docker de eclipse-temurin:26 para eclipse-temurin:27. Não mexeu em uma linha de código, não tocou em nenhuma flag da JVM, não mudou o requests.cpu do pod. Faz o deploy, vai tomar um café, e quando volta aquele microsserviço de 1 vCPU está gastando mais CPU e a latência sob carga começou a oscilar feio. O time de SRE abre um chamado, o time de dev jura que não mudou nada. E os dois estão certos.
O culpado tem nome: JEP 523, que chega no JDK 27 e faz o G1GC virar o coletor de lixo padrão em todos os ambientes, inclusive nos containers de 1 CPU que hoje rodam SerialGC sem você nem saber. O JDK 27 entrou em Rampdown Phase One em junho e tem GA marcada para 14 de setembro de 2026. Ou seja, tem uma janela curta pra você medir seus pods sub-dimensionados antes que esse default mude embaixo deles. Bora entender o que muda, como detectar e como fixar isso direito.
- Detalhes
- Escrito por: Jorge Demetrio
- Categoria Pai: Linguagem de programação
- Categoria: Java
-
Também disponível:
- Acessos: 170
Tem uma melhoria de garbage collector chegando que você ganha só de subir a versão. No JDK 27 o G1GC passa a ser o coletor padrão em todo ambiente, inclusive no seu container de 1 CPU que hoje roda SerialGC sem ninguém ter pedido. Sem flag nova, sem refatorar uma linha de código de negócio.
E o melhor: dá pra provar a diferença em uma linha de comando. Nesse artigo você vai entender por que tantos pods Java estão silenciosamente no SerialGC hoje, o que o JEP 523 muda na prática e como antecipar esse ganho antes mesmo do GA do JDK 27, marcado pra 14 de setembro de 2026.
- Detalhes
- Escrito por: Jorge Demetrio
- Categoria Pai: Linguagem de programação
- Categoria: Java
-
Também disponível:
- Acessos: 154
Sexta à tarde, pico de tráfego, e a aplicação que ia voar depois que você habilitou Virtual Threads congelou. Carriers presos, requisições penduradas sem resposta, o pool do banco no talo e o throughput despencando em vez de subir. Você jurou que era só ligar uma flag, né?
Pois é. O Loom não mentiu, só que ligar Virtual Threads no Java 25 não é mágica de configuração. Tem um punhado de armadilhas que ninguém conta nos tutoriais e que só aparecem na escala de produção: pinning de carrier, pool de conexão que vira o teto real, ThreadLocal multiplicado por milhões e carga CPU-bound disfarçada de I/O. A boa notícia: o JDK 25 já traz o JEP 491, que matou a pior delas. Bora ver as quatro, com código do jeito errado e do jeito certo, pra você não descobrir na marra.
- Detalhes
- Escrito por: Jorge Demetrio
- Categoria Pai: Linguagem de programação
- Categoria: Java
-
Também disponível:
- Acessos: 127
Dia 30 de junho de 2026 o Spring Boot 3.5 perde o suporte OSS. Depois dessa data, sem patch de segurança, sem correção de CVE, sem rede. E olha que a fila de CVE do Spring em 2026 foi a maior da história: só no patch day de 08/06 saíram 18 correções de uma vez. Quem ficar para trás vai rodar produção com buraco conhecido e sem remendo oficial.
O problema é que o caminho até o Spring Boot 4 não é um bump de versão tranquilo. São mais de 50 mudanças que quebram código de produção: Jackson 3 com group ID novo, Spring Security 7 obrigando o Lambda DSL, JSpecify ligando null-safety e o Spring AI 1.x simplesmente parando de funcionar. Nesse artigo eu te dou o checklist real, com código antes e depois, para você migrar sem descobrir cada armadilha na marra, às 2 da manhã de um deploy.
- Detalhes
- Escrito por: Jorge Demetrio
- Categoria Pai: Linguagem de programação
- Categoria: Java
-
Também disponível:
- Acessos: 205
Existe um jeito de rodar a mesma aplicação Java usando bem menos memória, sem refatorar serviço nenhum. A maioria dos devs ainda não ligou essa configuração porque ela era opt-in, escondida atrás de uma flag experimental. No JDK 27 ela vira padrão, e quem entende o porquê sai na frente.
O recurso se chama Compact Object Headers (JEP 534) e, em benchmark oficial, corta cerca de 22% do heap e 8% de CPU. Bora ver, na prática, o que muda no cabeçalho de cada objeto que a sua JVM cria, como medir esse ganho no seu próprio código e em quais cenários ele realmente compensa.
- Detalhes
- Escrito por: Jorge Demetrio
- Categoria Pai: Linguagem de programação
- Categoria: Java
-
Também disponível:
- Acessos: 176
O Spring Security 7.0 GA entrou no release train de junho de 2026 junto com o Spring Boot 4.0. E tem um detalhe que ninguem te avisou no calendario: o Spring Boot 3.5 perde suporte OSS em 30 de junho de 2026. Ou seja, o relogio da migracao ja esta correndo, e o seu SecurityConfig e a primeira coisa que vai quebrar no build.
Se voce ja tentou subir um projeto pro Boot 4 e tomou uma chuva de erros de compilacao no filtro de seguranca, este artigo e pra voce. Bora destrinchar, na pratica, tudo que mudou no Security 7 e montar um checklist de migracao com codigo antes e depois, do jeito que os seniores fazem.
- Detalhes
- Escrito por: Jorge Demetrio
- Categoria Pai: Linguagem de programação
- Categoria: Java
-
Também disponível:
- Acessos: 162
Você atualizou a versão do Spring AI, subiu pra homologação e o agente simplesmente parou de chamar as ferramentas. Sem erro. Sem stack trace. Sem nada nos logs. O modelo responde como se as tools nunca tivessem existido, e você acabou de gastar a tarde procurando bug no lugar errado.
Esse cenário vai ser comum quando o Spring AI 2.0 chegar ao GA. O RC1, lançado em 6 de junho de 2026, removeu o loop interno de execução de tools de todos os ChatModels. Se o seu código ainda registra ferramentas por nome com toolNames(), elas vão virar fantasma. Nesse artigo você vai ver exatamente o que mudou e como migrar antes que o GA te pegue desprevenido.
- Detalhes
- Escrito por: Jorge Demetrio
- Categoria Pai: Linguagem de programação
- Categoria: Java
-
Também disponível:
- Acessos: 185
Você abriu a vaga de Backend Sênior, leu "experiência com IA generativa no ecossistema Java" e pensou que sabia o suficiente. Aí veio a pergunta que separou a sala: "qual a diferença entre Spring AI 1.x e 2.0, e o que quebra no seu tool calling quando você migra?". Quem só tinha lido o título do release travou ali.
A partir de junho de 2026, essa pergunta entrou no roteiro das entrevistas técnicas de backend Java. O Spring AI 2.0 chegou em release candidate carregando o Spring Boot 4 como dependência obrigatória, e mudou o jeito como as ferramentas (tools) são executadas. Bora ver, na prática, o código antes e depois e a resposta que mostra senioridade de verdade.
- Detalhes
- Escrito por: Jorge Demetrio
- Categoria Pai: Linguagem de programação
- Categoria: Java
-
Também disponível:
- Acessos: 189
Existe uma forma de fazer seu microservice Java subir em 50 milissegundos em vez de 8 segundos, sem reescrever uma linha da regra de negócio. A maioria dos devs ainda empacota a JVM inteira dentro do container e paga a conta disso todo mês no Fargate.
Com GraalVM Native Image e o AWS SDK for Java 2.x, você compila a aplicação para um binário nativo e o startup despenca de cara. Nesse artigo você vai montar o build do zero, com Maven, Dockerfile e deploy no Fargate, e ainda vai entender por que essa decisão virou pergunta de entrevista sênior em fintech.
- Detalhes
- Escrito por: Jorge Demetrio
- Categoria Pai: Cloud Computing
- Categoria: Cloud AWS
- Acessos: 154
Em abril de 2026, ferramentas de IA varreram o ecossistema Spring e encontraram 26 CVEs em um único mês. A release train que deveria chegar em maio foi adiada duas vezes. Chega agora, semana de 8 a 14 de junho. Se você tem Spring em produção, esta é a semana para agir.
- Detalhes
- Escrito por: Jorge Demetrio
- Categoria Pai: Linguagem de programação
- Categoria: Java
- Acessos: 185
JDK 27 entrou em Rampdown Phase One em 4 de junho de 2026. GA previsto para 14 de setembro de 2026. Dois JEPs vão reduzir o footprint de memória de toda app Java em produção sem alterar uma linha de código: JEP 534 (Compact Object Headers por padrão) e JEP 523 (G1GC como default universal).
- Detalhes
- Escrito por: Jorge Demetrio
- Categoria Pai: Linguagem de programação
- Categoria: Java
- Acessos: 179