O Spring Boot 4.2 RC1 já está disponível, mas colocar essa versão na API de produção agora exige uma justificativa melhor do que “saiu uma atualização”. A versão ainda é candidata a lançamento. Para uma equipe que precisa manter o serviço funcionando, o uso mais útil neste momento é descobrir incompatibilidades em um ambiente de avaliação, enquanto a linha estável segue seu processo normal de manutenção.
Em 23 de outubro de 2026, o projeto anunciou o 4.2.0-RC1 e o 4.1.2. O primeiro antecipa mudanças da próxima linha; o segundo é uma atualização estável. A documentação de atualização da linha 4.2 ainda identifica essa linha como em desenvolvimento. Essa diferença deve aparecer no planejamento do deploy, principalmente quando uma mesma equipe cuida da aplicação, da imagem do contêiner e do pipeline.
Spring Boot 4.2 RC1: o que merece atenção no anúncio
O anúncio oficial do RC1 destaca a troca do builder padrão do Buildpacks para paketobuildpacks/ubuntu-resolute-builder, baseado no Ubuntu 26.04, a possibilidade de o migrador de propriedades interromper a inicialização e melhorias de startup na busca de classes e recursos de JARs executáveis. São mudanças que atingem pontos diferentes da operação.
O builder interessa a quem usa o fluxo de construção de imagens compatível com essa configuração. Uma aplicação empacotada por um Dockerfile próprio precisa ser analisada pelo caminho que realmente usa. Trocar o número do Boot no arquivo de build e presumir que todas as imagens mudaram da mesma forma produz um inventário errado. Antes de avaliar impacto, registre qual comando gera a imagem entregue ao cluster.
Também seria precipitado transformar a menção a startup em uma porcentagem de ganho. O anúncio não mede a sua aplicação, suas dependências nem a latência do seu ambiente. Uma comparação útil precisa guardar o artefato, o JDK, os limites de CPU e memória e a definição de “pronta”: processo iniciado, porta aberta e capacidade de atender uma operação de negócio são marcos diferentes.
O erro comum: mudar framework, runtime e imagem juntos
Imagine uma API de pedidos que recebe o RC, um JDK diferente e uma imagem base nova no mesmo deploy. Se a inicialização falhar ao carregar um certificado ou uma biblioteca nativa, a equipe terá várias hipóteses concorrentes. Esse é um cenário hipotético para planejamento, não o relato de um incidente ocorrido no Javalizando.
A causa do retrabalho é a falta de uma comparação controlada. O sintoma costuma ser um teste que passa na máquina do desenvolvedor e falha no contêiner. Uma avaliação melhor conserva primeiro as condições conhecidas, identifica as mudanças obrigatórias da atualização e registra cada alteração adicional. Quando duas mudanças forem inseparáveis, documente essa dependência em vez de fingir que foram avaliadas isoladamente.
Quem já está planejando uma troca de JDK pode separar essa decisão com o roteiro de avaliação do Java 27 para backend. O objetivo aqui é examinar o candidato do framework. Transformar o ensaio em uma migração geral da plataforma torna o diagnóstico mais caro e dificulta entender qual mudança trouxe o problema.
Spring Boot 4.2 RC1 e o migrador como barreira temporária
Na linha 4.2, a propriedade spring.properties.migrator.fail aceita never, on-error e on-warning. O padrão é never. Com o módulo spring-boot-properties-migrator presente, on-error faz a aplicação falhar diante de propriedades não mais suportadas; on-warning também cobre propriedades renomeadas. Os diagnósticos continuam sendo registrados independentemente dessa escolha.
Isso permite um uso específico em um ensaio de CI: executar a inicialização com uma política mais rigorosa, tratar o diagnóstico e repetir o teste. O módulo deve ser removido ao concluir a migração, como orienta a documentação. Ele também não examina propriedades adicionadas tarde ao ambiente, como em certos usos de @PropertySource; por isso, uma execução sem avisos não comprova que toda configuração foi validada.
Considere uma segunda situação hipotética: homologação recebe valores por arquivo, mas produção recebe parte das propriedades pelo orquestrador. Validar somente o arquivo pode deixar uma diferença relevante escondida. Uma boa evidência de migração inclui os nomes das propriedades efetivas por ambiente, com segredos suprimidos, e confirma que o perfil esperado foi carregado.
O artigo sobre profiles e arquivos de configuração no Spring Boot ajuda nessa revisão. Uma configuração de teste não deve apontar para banco, fila ou serviço de cobrança reais. O isolamento precisa existir antes de iniciar o candidato, inclusive quando a aplicação dispara jobs ou consumidores automaticamente.
Avaliação na prática: um roteiro que deixa evidências
Em um checkout separado do projeto, faça a alteração de versão conforme o mecanismo usado pela aplicação, como parent ou BOM. Revise também as notas das versões intermediárias se estiver vindo de uma linha mais antiga. O bloco abaixo pressupõe um projeto Maven com wrapper e gera evidências do build; ele não altera sozinho a versão do Boot e não publica nenhum artefato.
#!/usr/bin/env sh
set -eu
# Execute no checkout de avaliação, após revisar a versão no pom.xml.
./mvnw -B clean verify
mkdir -p target/avaliacao-boot
./mvnw -B help:effective-pom \
-Doutput=target/avaliacao-boot/effective-pom.xml
./mvnw -B dependency:tree \
-DoutputFile=target/avaliacao-boot/dependencies.txt
java -version 2> target/avaliacao-boot/java-version.txt
printf '%s\n' 'Build e inventário concluídos. Falta avaliar a aplicação em execução.'
Esse roteiro é uma proposta operacional para adaptar ao projeto. Não executamos uma migração completa para o RC1 nem medimos seu desempenho. O resultado de verify depende dos testes configurados no build: se a suíte de integração não estiver ligada a essa fase, o comando não passa a executá-la por intenção. Confira os plugins, os perfis e o relatório de testes antes de chamar o build de aprovado.
Depois do build, inicie o artefato no ambiente isolado e exerça uma operação que atravesse HTTP, regra de negócio e persistência. Inclua uma resposta de erro contratual e uma dependência indisponível. Um endpoint de saúde verde pode coexistir com uma integração quebrada; os sinais necessários para essa leitura estão na discussão sobre erros de observabilidade com Actuator e Prometheus.
Quando usar o candidato e quando evitar
O RC faz sentido em uma avaliação antecipada quando a equipe consegue reproduzir falhas e tem tempo para verificar extensões, starters e bibliotecas que usa. Pode ser especialmente útil se uma mudança anunciada resolve uma necessidade concreta do projeto. O custo é manter um ambiente adicional e aceitar que o candidato ainda pode mudar antes da versão final.
Evite tratá-lo como atualização rotineira de produção quando faltam testes representativos, inventário de dependências ou uma estratégia de retorno. Para manutenção da linha estável, o anúncio do Spring Boot 4.1.2 é uma referência distinta. “Estável” também não dispensa homologação, e não significa que toda aplicação em uma linha anterior deva migrar imediatamente.
Defina critérios antes do ensaio: quais contratos precisam permanecer iguais, qual erro impede o avanço e quem avalia uma regressão. Guarde a imagem anterior e verifique sua compatibilidade com mudanças de dados. Se o ensaio exigir uma migração de esquema irreversível, voltar a imagem não basta para reverter o sistema; essa dependência precisa aparecer na decisão.
FAQ sobre a avaliação do RC
Spring Boot 4.2 RC1 já é a versão estável?
Não. Em 29 de outubro de 2026, a documentação consultada apresenta o 4.2.0-RC1 como versão em desenvolvimento e aponta o 4.1.2 como estável. Verifique novamente o estado do lançamento quando for planejar sua atualização, porque esse status muda com o calendário do projeto.
Posso concluir que minha API vai iniciar mais rápido?
O anúncio menciona melhorias de startup, mas isso não determina o ganho da sua API. Compare os mesmos marcos de inicialização em condições equivalentes e registre variação entre execuções. Sem esse teste, qualquer porcentagem atribuída ao projeto seria uma estimativa sem evidência.
Devo deixar o properties migrator em produção?
A orientação do Spring é remover o módulo depois da migração. Use seus diagnósticos durante a avaliação, corrija as propriedades e confirme o comportamento sem a dependência temporária antes de considerar o trabalho concluído.
Conclusão: prepare a decisão de atualização
O próximo passo útil é abrir um checkout de avaliação, registrar as versões efetivas e escolher uma operação de negócio para comparar com o ambiente atual. A decisão de migrar deve citar o que foi validado, o que falhou e o que continua desconhecido. Como leitura complementar, o roteiro de runtime, a revisão de profiles e a análise de observabilidade já ligados acima cobrem partes diferentes desse trabalho. Uma avaliação documentada agora reduz a investigação necessária quando a versão final entrar no planejamento.