⚙️ JDK 27 remove -noverify e -Xverify:none: o CI quebra
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.
⚙️ JDK 27: G1GC vira padrão no container Kubernetes
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.
🚨 Alerta "Misantropia": foi a Defesa Civil mesmo?
Era quase meia-noite de sexta-feira, 19 de junho de 2026, quando vários celulares em Curitiba começaram a tocar sozinhos. Não foi um toque qualquer: era a sirene estridente dos alertas extremos, aquela que dispara mesmo com o aparelho no silencioso. Na tela, sob o cabeçalho "DEFESA CIVIL", uma única palavra, sem chuva, sem temporal, sem instrução de abrigo: "Misantropia". Quem recebeu descreveu o mesmo: susto, confusão e a sensação de que algo muito errado estava acontecendo.
A reação imediata foi lógica. Se a tela diz "Defesa Civil", então o sistema da Defesa Civil mandou, certo? E se mandou uma palavra dessas, foi invadido. Foi essa a leitura que correu pelas redes na madrugada de sábado (20), com gente afirmando que "invadiram o sistema de alertas do governo" e até que "todos os celulares do Brasil" receberam. Acontece que a história técnica por trás dessa tela é mais interessante (e menos apocalíptica) do que o pânico sugere. Como Tech Leader, aprendi cedo que a aparência de um sistema raramente prova sua origem, e este caso é um exemplo de manual disso.
♻️ G1GC de graça no JDK 27: pod 1 CPU sem mexer no código
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.
🧵 Liguei Virtual Threads e a produção travou: o que ninguém conta
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.
⏰ Spring Boot 3.5 chega ao fim em 30/06: migre antes
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.
🚀 Como cortar 22% do heap da JVM sem mudar uma linha
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.
🔐 Spring Security 7 GA chegou: migre o filtro antes do EOL
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.
⚡ Spring AI 2.0 RC1 vai quebrar seu tool calling: migre já
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.
🚀 GraalVM Native: o jeito sênior de cortar custo na AWS
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.
A release de segurança do Spring que foi adiada duas vezes chega esta semana: o que atualizar
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.
JDK 27 em Rampdown: como Compact Object Headers vai cortar automaticamente o heap do seu Pod
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).
O código de tools que vai quebrar no Spring AI 2.0 (e o que fazer agora)
Se você tem código Spring AI que usa toolNames(), SpringBeanToolCallbackResolver ou depende do loop interno de tool execution dentro do ChatModel, ele vai quebrar quando o Spring AI 2.0 GA sair. O RC1 lançado em 06/06/2026 consolida todas as mudanças. Aqui está o guia completo com before/after para cada breaking change do Tool Calling Overhaul.
Página 1 de 27