Fim do ciclo de vida do OpenJDK 17: datas importantes, suas opções e suporte

Principais conclusões

• O OpenJDK 17 não tem uma data única de fim de vida útil, e o suporte dos fornecedores se estende de setembro de 2026 até, pelo menos, outubro de 2029.
• Quando o suporte for encerrado, as correções de vulnerabilidades CVE serão interrompidas, e ficará mais difícil passar nas auditorias de conformidade e nas renovações de seguro.
• As equipes que ainda não estiverem prontas para a migração podem continuar recebendo patches para vulnerabilidades CVE por meio do suporte estendido de terceiros, sem precisar alterar seu ambiente de execução ou código.

Se suas cargas de trabalho de produção ainda estiverem no OpenJDK 17, você está em boa companhia. O Java 17 foi a escolha “segura” de LTS por um motivo — é estável, conta com bom suporte e é amplamente compatível. O problema é que “suporte” agora tem um significado diferente dependendo da distribuição que você estiver executando, e essas datas não são as mesmas.

Este artigo aborda o que o fim da vida útil (EOL) do OpenJDK 17 realmente significa na prática, as datas específicas para as compilações mais comuns, por que a migração é mais difícil do que a documentação dá a entender e quais são suas opções reais quando o prazo está mais próximo do que a base de código está preparada para lidar.

Visão geral do ciclo de vida e do suporte do OpenJDK

O OpenJDK é a implementação de referência de código aberto do Java SE, gerenciada pela Oracle. Mas não é a mesma coisa que o “Oracle JDK” – e essa distinção é exatamente o que torna o planejamento do fim da vida útil (EOL) confuso.

A comunidade OpenJDK (upstream) oferece suporte a uma versão principal por aproximadamente seis meses, até o lançamento da próxima versão com novos recursos. O suporte de longo prazo (LTS) é uma questão do downstream, administrada pelos fornecedores que criam pacotes e aplicam correções em suas próprias compilações. Desde que o Java passou a ter um ciclo de lançamento de seis meses, apenas determinadas versões recebem a designação LTS. O Java 17 é uma delas. O Java 21 e o Java 25 são versões LTS mais recentes.

Veja a seguir a situação atual das versões LTS:

A adoção ainda está bem aquém dessas datas. O Relatório de Produtividade do Desenvolvedor Java 2025, da JRebel, constatou que 61% dos entrevistados ainda utilizam o Java 17. Na amostra mais ampla, 72% relataram usar distribuições da Oracle fora do suporte público gratuito, incluindo 35% no Java 8 e 32% no Java 11. É provável que sua equipe esteja gerenciando pelo menos uma versão em fim de vida (EOL) paralelamente à versão para a qual você planeja migrar.

Principais datas do OpenJDK 17

O ponto mais importante a se entender: não existe uma data única para o fim do ciclo de vida (EOL) do OpenJDK 17. Cada distribuição segue seu próprio cronograma.

As duas datas que a maioria das equipes deve ter em mente neste momento são o fim do suporte do Premier Support da Oracle, em setembro de 2026, e o da Red Hat, em dezembro de 2027. Se você estiver usando o Oracle JDK 17 sem uma Assinatura Universal, as atualizações de segurança gratuitas foram interrompidas em setembro de 2024. Para continuar recebendo atualizações, é necessário ter uma Assinatura Universal paga do Oracle Java SE.

Para uma análise completa das diferenças entre as compilações do Oracle e do OpenJDK em termos de licenciamento e suporte, consulte nosso guia “OpenJDK x Oracle JDK ”.

O Java 17 foi a versão LTS lançada quando a Oracle anunciou a mudança para um ciclo de LTS de dois anos; a partir do Java 21, o intervalo entre os lançamentos LTS passou de três para dois anos. Com esse ciclo mais curto, a pressão para atualização agora atinge as empresas a cada dois anos, em vez de três — mas os cronogramas de migração da maioria das equipes ainda não foram ajustados para acompanhar essa mudança.

O que realmente acontece quando o OpenJDK 17 chega ao fim do ciclo de vida?

Sua JVM continua funcionando. É isso que leva as equipes a ignorarem as datas de fim de vida útil (EOL) — nada para de funcionar logo no primeiro dia. O aplicativo que estava funcionando bem ontem parece exatamente o mesmo amanhã. O que muda é o que está acontecendo a montante. Ou, mais precisamente, o que deixa de acontecer.

Três fatores começam a acumular risco em segundo plano após o fim da vida útil (EOL).

1. Suspensão das atualizações de segurança

Essa é a grande questão. Após o EOL, o mantenedor deixa de fazer o backport de correções de CVE para a sua versão. Novas vulnerabilidades encontradas nos mecanismos internos da JVM, na biblioteca padrão, nas implementações de TLS, nos caminhos de desserialização — nenhuma delas será corrigida na sua compilação. Elas serão corrigidas no Java 21 e no 25. A sua versão simplesmente permanece como está.

A JVM não é um alvo insignificante. O Java esteve envolvido em algumas das classes de vulnerabilidades mais exploradas na última década, e novos CVEs continuam surgindo a cada ciclo trimestral de Atualizações Críticas de Patches. Quando sua versão sai dessa lista, você passa a acumular todas as falhas sem correção que surgirem entre o fim da vida útil (EOL) e o momento em que você finalmente concluir a migração.

2. A conformidade fica mais difícil

A maioria das estruturas de conformidade — PCI DSS, HIPAA, SOC 2, FedRAMP, ISO 27001 — possui requisitos explícitos ou implícitos relativos à execução de softwares compatíveis com patches atualizados. Os auditores estão cada vez mais exigentes quanto a isso, e “estávamos planejando fazer a atualização” não é uma resposta satisfatória em um relatório de constatações.

Utilizar uma versão do Java em fim de vida útil (EOL) coloca você na situação de:

• Falhas em varreduras automatizadas de vulnerabilidades – o Nessus, o Qualys, o Wiz e ferramentas semelhantes sinalizam ambientes de execução em fim de vida (EOL) por padrão
• Dedicar tempo extra para documentar e justificar exceções em cada ciclo de auditoria
• Um desafio para as renovações de seguros cibernéticos – várias grandes seguradoras agora perguntam diretamente se há software em fim de vida útil (EOL) em uso na produção
• Alegar que a divulgação da violação ocorreu porque “sabíamos que não havia fundamento” é algo muito difícil de explicar após um incidente

Análise da realidade: O Relatório Anual de Investigação sobre Violações de Dados (DBIR) da Verizon de 2025 constatou que a exploração de vulnerabilidades como vetor de acesso inicial cresceu 34% em relação ao ano anterior, representando agora 20% das violações. Ambientes de execução sem patches são exatamente onde isso ocorre.

3. A deterioração das dependências é um problema de evolução lenta

Isso pega de surpresa as equipes que acham que já se planejaram com antecedência. Mesmo que seu ambiente de execução Java permaneça na versão 17, o restante da sua pilha não fica estagnado junto com ele.

As estruturas deixam de oferecer suporte a JDKs mais antigos. O Spring Boot lança uma nova versão principal a cada ano e eleva rotineiramente seu padrão de referência. Os mantenedores de bibliotecas deixam de realizar testes com JVMs em fim de vida (EOL). As imagens base dos contêineres são recompiladas com base em JDKs mais recentes. Em algum momento, você se depara com uma atualização de dependência em que uma biblioteca transitiva exige um recurso que só existe no Java 21 ou superior, e a atualização que você vem adiando há dois anos de repente precisa ser feita neste sprint — no pior momento possível.

Por que a atualização nem sempre é simples

A transição do Java 17 para o 21 ou o 25 é, de fato, mais tranquila do que a maioria das migrações para versões principais realizadas no passado. Mas isso não significa que seja barata. É nesse ponto que as equipes realmente enfrentam dificuldades.

Suas dependências ainda não estão todas prontas

A atualização da versão do Java não se resume apenas à troca da JVM. Envolve todas as bibliotecas, frameworks e artefatos internos que estão vinculados a um nível específico de bytecode ou que dependem de mecanismos internos que sofreram alterações entre as versões.

As falhas comuns na rota 17 → 21 incluem:

• Bibliotecas com uso intenso de reflexão que se deparam com regras de encapsulamento mais rígidas
• Ferramentas mais antigas de manipulação de bytecode — ASM, algumas versões do Byte Buddy, versões mais antigas do Hibernate — que precisam de atualizações significativas
• Codifique usando sun.misc.Unsafe encontrar avisos de descontinuação ou APIs que foram removidas completamente
• Ferramentas de compilação (Maven Surefire, Gradle, JaCoCo) que exigem atualizações de versão em sincronia
• Imagens de contêineres e executores de CI que precisam de atualizações paralelas

Uma equipe que trabalha com um monólito de quatro anos geralmente só descobre a maior parte disso depois que o ramo de atualização chega ao CI. É preciso reservar verba para isso.

Sua cobertura de testes provavelmente não é tão boa quanto parece

As atualizações da JVM revelam bugs que os testes unitários não detectam. O comportamento da coleta de lixo muda de uma versão para outra. As configurações padrão sofrem alterações. O compilador JIT toma decisões diferentes. O tratamento de configurações regionais, o tratamento de fusos horários, o comportamento do mecanismo de expressões regulares — todos esses fatores já causaram incidentes reais em produção em atualizações anteriores.

Se o seu conjunto de testes não simular bancos de dados reais, E/S reais e perfis de carga realistas, a atualização será aprovada na integração contínua (CI), mas falhará em produção. Essa é a parte do plano de migração que acaba sendo discretamente ignorada e é a origem da maioria das análises pós-falha do tipo “já fizemos a atualização, por que tudo está dando errado?”.

O calendário não corresponde ao código-fonte

Mesmo quando a migração técnica é viável, a realidade organizacional muitas vezes não é. A capacidade da equipe de engenharia é alocada trimestre a trimestre. A atualização compete com o desenvolvimento de novos recursos, com as pendências de segurança e com qualquer incidente que esteja ocupando a atenção da equipe naquela semana. Uma estimativa de migração de três meses no papel acaba se transformando em uma migração de nove meses na prática, porque ninguém consegue dedicar tempo ininterrupto a ela.

Da prática: Um padrão comum: uma equipe planeja a atualização do Java 17 para o 21 no primeiro trimestre, esbarra em um conflito de versão principal do Spring Boot, adia para o segundo trimestre, é envolvida em um ciclo de preparação para a auditoria SOC 2 e tudo acaba sendo adiado para o quarto trimestre. Nessa altura, o Java 25 já está disponível e a meta muda novamente. As equipes que realmente cumprem seus prazos tratam as datas de fim de vida útil (EOL) como marcos rígidos do projeto, com responsáveis designados — e não como itens pendentes que serão resolvidos “em algum momento”.

Suas opções após o fim do ciclo de vida (EOL) do OpenJDK 17

Não existe uma resposta única e correta. O melhor caminho depende da sua capacidade de engenharia, do grau de rigidez da sua pilha de tecnologias e do nível de exigência dos seus requisitos de conformidade. Aqui estão as opções viáveis.

Opção 1: Suporte estendido de terceiros para o OpenJDK 17

Se a atualização não for viável dentro do seu cronograma atual, o suporte de ciclo de vida estendido oferecido por terceiros é a maneira mais simples de continuar recebendo patches de CVE sem alterar seu ambiente de execução nem refatorar seu código. Essa abordagem funciona particularmente bem para equipes que utilizam o OpenJDK 17 em distribuições Linux mistas — RHEL, AlmaLinux, Rocky, Ubuntu, Debian —, nas quais os ciclos de vida de suporte do sistema operacional e do JDK não se alinham perfeitamente.

O Suporte de Ciclo de Vida Ilimitado da TuxCare para o OpenJDK oferece patches de segurança contínuos para as versões 17, 11, 8 e 7 do OpenJDK – abrangendo a maioria das principais distribuições Linux corporativas. A abordagem é simples: você mantém suas compilações existentes, continua recebendo patches à medida que novos CVEs são identificados e ganha tempo para planejar uma migração bem planejada, em vez de uma apressada. Ele foi projetado especificamente para equipes com restrições regulatórias que não podem tolerar a execução de ambientes de execução sem patches, mas também não podem deixar tudo de lado para realizar uma grande atualização de versão neste trimestre.

Opção 2: Atualizar para o Java 21 ou o Java 25

A solução certa a longo prazo para a maioria das equipes. Se você dispõe de recursos de engenharia, a atualização para uma versão LTS atual oferece anos de suporte público gratuito, melhorias significativas de desempenho e compatibilidade contínua com o ecossistema à medida que ele evolui. De acordo com o roteiro de suporte da Oracle, o Java 21 conta com Suporte Premier até setembro de 2028 e o Java 25 até setembro de 2030 — embora, se você estiver usando o Corretto, o Temurin ou outra versão, verifique o cronograma específico do seu fornecedor.

Essa é a decisão certa quando:

• Sua base de código é pequena ou está suficientemente testada para ser migrada em um trimestre
• Sua cobertura de CI irá, de fato, detectar mudanças de comportamento, e não apenas falhas de compilação
• Suas principais dependências já oferecem suporte ao Java 21 e versões posteriores
• Você pode organizar um sprint de engenharia bem focado sem que ele seja puxado em três direções diferentes

Opção 3: Mudar para uma distribuição diferente do OpenJDK

Se você estiver usando o Oracle JDK 17 e a mudança no licenciamento prevista para setembro de 2024 o pegou de surpresa, não é necessário migrar para o Java 21 agora mesmo para contornar o problema de licenciamento. Você pode mudar para o Eclipse Temurin, o Amazon Corretto ou a versão do OpenJDK desenvolvida pela Microsoft sem alterar seu código Java — todas essas opções são certificadas pelo TCK e apresentam comportamento idêntico para a grande maioria das cargas de trabalho.

A migração para longe do Oracle JDK já vem ocorrendo há alguns anos – os dados da New Relic mostram que a participação da Oracle no mercado de JDK caiu de 75% em 2020 para 21% em 2024, enquanto o Eclipse Adoptium cresceu 50% em relação ao ano anterior. A maioria das equipes que migrou não precisou alterar nenhuma linha de código Java para fazer isso.

Algumas coisas a verificar antes de mudar:

• Confirme a data de fim de vida útil (EOL) da nova distribuição do Java 17 – elas variam de um a três anos
• Verifique se há opções ou extensões da JVM específicas do fornecedor (algo raro, mas que vale a pena ser verificado)
• Atualize o provisionamento, as imagens de contêiner e a CI para que sejam obtidas da nova fonte
• Documentar a alteração para fins de registros de conformidade

Atenção: Mudar de distribuição é uma medida tática, não uma solução de longo prazo. O Corretto 17 e a versão da Microsoft estendem o suporte além do prazo da Red Hat em alguns casos, mas todos eles chegam ao fim eventualmente. Use a mudança para ganhar um prazo de 12 a 24 meses — não como um motivo para deixar de planejar a migração propriamente dita.

Opção 4: Aceitar o risco (deliberadamente)

Algumas equipes realmente tomam essa decisão e, em certos contextos, isso é justificável. Ferramentas internas, ambientes isolados, cargas de trabalho descartáveis — nem tudo justifica o custo de engenharia de um ambiente de execução atualizado.

Tome a decisão de forma consciente, documente-a e segmente o risco para que uma JVM sem patch não fique em um endpoint voltado para o público. Combine isso com uma abordagem automatizada de gerenciamento de patches para o restante da sua pilha, de modo que o componente sem suporte não se torne, por padrão, o elo mais fraco. Além disso, entenda a diferença entre gerenciamento de patches e gerenciamento de vulnerabilidades — não são a mesma disciplina, e é justamente ao confundir os dois que os componentes sem suporte acabam passando despercebidos.

Protegendo o OpenJDK após o fim do ciclo de vida (EOL) com a TuxCare

A verdade incômoda sobre o fim da vida útil (EOL) do Java é que “o ambiente de execução ainda funciona” é exatamente o que torna fácil deixar isso de lado. As correções param, as dependências se deterioram, as constatações de auditoria se acumulam — e então, um dia, surge um CVE com um exploit funcional e sua versão não está na lista de correções.

Se sua equipe está utilizando o OpenJDK 17 e o cronograma de migração previsto no papel não está correspondendo à realidade, essa não é uma situação incomum. A atualização é a solução correta a longo prazo. Mas se você ainda precisa de um ou dois trimestres para estar pronto para executá-la adequadamente, continuar utilizando a versão sem patches nesse meio tempo representa um risco real.

O Suporte de Ciclo de Vida Ilimitado da TuxCare para o OpenJDK foi desenvolvido para esse período — mesmas compilações, mesmos fluxos de trabalho e correções de CVE que não expiram quando o calendário de suporte do desenvolvedor original indica que deveriam. Ele abrange as versões 7, 8, 11 e 17 do OpenJDK em sistemas Enterprise Linux e baseados em Debian, pelo tempo que sua organização precisar. Consulte os preços ou entre em contato com os especialistas da TuxCare para avaliar como seria a cobertura para o seu ambiente.

Resumo

Nome do artigo

Fim do ciclo de vida do OpenJDK 17: datas importantes, suas opções e suporte

Descrição

Datas de fim de vida útil do OpenJDK 17, cronogramas de suporte, diferenças entre fornecedores e opções de atualização. Saiba o que significa EOL e como se preparar para o Java 17.

Autor

Rohan Timalsina

Nome da editora

TuxCare

Logotipo da editora