Fim do ciclo de vida do OpenJDK 11: datas, riscos e suas opções (Guia para 2026)

Principais conclusões

• Os patches de segurança gratuitos do OpenJDK 11 chegaram ao fim no final de 2024 — se você não tiver contratado o suporte estendido, todas as vulnerabilidades CVE identificadas desde então permanecem sem correção em seu ambiente de execução.
• A data efetiva de fim de vida útil (EOL) depende da versão do fornecedor que você utiliza, e não de uma data única para toda a comunidade.
• A atualização para o Java 17 ou 21 é a decisão certa a longo prazo, mas a dependência de bibliotecas e as pilhas de aplicativos certificadas tornam isso mais difícil do que parece.
• O suporte estendido ao ciclo de vida oferecido por fornecedores ou terceiros, como a TuxCare, permite que você mantenha o OpenJDK 11 atualizado com os patches enquanto planeja a migração de acordo com seu próprio cronograma.

Se você está utilizando o OpenJDK 11 em produção atualmente, já passou do ponto crítico. Os patches gratuitos da comunidade deixaram de ser lançados no final de 2024, e todas as vulnerabilidades CVE publicadas desde então permanecem sem correção em seu ambiente de execução, a menos que alguém esteja pagando por isso.

O fim do ciclo de vida do OpenJDK 11 não é mais algo que você precisa levar em conta nos seus planos — isso já aconteceu, e sua postura de segurança vem se deteriorando gradualmente por causa disso. Este guia apresenta as datas reais, o que muda quando o suporte da comunidade termina e as opções viáveis disponíveis quando “basta atualizar para o Java 17” não é algo que você consiga realmente concluir neste trimestre.

Visão geral do ciclo de vida do OpenJDK

O OpenJDK não possui um ciclo de vida de suporte único e unificado — e essa é a primeira coisa que causa dificuldades às equipes.

O próprio projeto OpenJDK, na fonte, se compromete apenas com seis meses de atualizações por versão. Todos os outros prazos que você já viu vêm de um fornecedor derivado: Red Hat, Oracle, Amazon, Azul, Microsoft, Eclipse Adoptium. Cada um deles lança sua própria compilação e define sua própria data de fim de vida útil (EOL).

Essa distinção é mais importante do que a maioria das pessoas imagina. Os termos “fim de vida útil” e “fim do suporte” são usados de forma intercambiável até que apareça um CVE — e, então, de repente, a diferença passa a ser extremamente importante. EOL geralmente significa “não haverá mais atualizações gratuitas deste fornecedor”. Fim do suporte significa “não há ajuda disponível em lugar algum, seja paga ou gratuita”. No caso do OpenJDK, você pode chegar ao EOL com seu fornecedor atual e ainda assim encontrar suporte pago em outro lugar. Esse é exatamente o objetivo dos programas de suporte estendido oferecidos por fornecedores e terceiros.

Aqui está um mapa geral do que cada fase do ciclo de vida realmente oferece:

É bom saber: A classificação “LTS” nas versões Java 8, 11, 17, 21 e 25 é uma convenção dos fornecedores, não um compromisso do OpenJDK. A Oracle deu início a isso; o restante do ecossistema seguiu o exemplo. O projeto em si avança a cada seis meses, independentemente do que estiver instalado no seu servidor.

Tipos de versão do OpenJDK

O OpenJDK é lançado a cada seis meses, mas os fornecedores tratam essas versões de maneira muito diferente, dependendo se são LTS ou não.

Lançamentos LTS

As versões LTS são aquelas que os fornecedores se comprometem a manter por anos. Java 8, 11, 17, 21 e 25 são as versões LTS atuais. Elas recebem patches de segurança retroativos, correções de bugs e Atualizações Críticas de Patches trimestrais dos principais fornecedores. Se você estiver executando qualquer sistema em produção, certamente vai querer uma versão LTS — é exatamente por isso que elas existem.

O suporte da comunidade geralmente inclui patches de segurança e correções de bugs gratuitos, mas termina na data de fim de vida útil (EOL) declarada para cada versão. A partir desse momento, as atualizações só estão disponíveis por meio de programas de suporte estendido específicos do fornecedor ou de terceiros.

Além da comunidade OpenJDK, os fornecedores e as distribuições oferecem suas próprias compilações e cronogramas de suporte para as versões do OpenJDK. Esses cronogramas também variam, e compreender as principais diferenças entre o OpenJDK e o Oracle JDK pode ajudá-lo a escolher a distribuição certa para sua estratégia de suporte de longo prazo.

Versões não LTS

As versões não LTS (Java 9, 10, 12, 13, 14, 15, 16, 18, 19, 20, 22, 23, 24, 26) recebem seis meses de atualizações e, em seguida, deixam de receber suporte ativo. Elas se destinam a desenvolvedores que desejam acesso antecipado a novos recursos, e não para cargas de trabalho em produção. De acordo com o relatório “2024 State of the Java Ecosystem” da New Relic, menos de 2% dos aplicativos em produção rodam uma versão não LTS — o que faz sentido, pois fazer isso equivale, essencialmente, a se comprometer com uma atualização forçada a cada seis meses.

Níveis de suporte estendido

Além do LTS padrão, os fornecedores oferecem fases adicionais de suporte estendido pagas. A Oracle oferece às versões LTS cinco anos de Suporte Premier, seguidos por três anos de Suporte Estendido e, posteriormente, Suporte de Manutenção por tempo indeterminado — que não inclui correções de segurança. A Red Hat oferece uma estrutura semelhante, com uma fase ELS-1 separada para o OpenJDK 11 como um complemento pago. Ofertas de terceiros, como o Endless Lifecycle Support da TuxCare para o OpenJDK, vão um passo além, oferecendo correções contínuas de CVEs pelo tempo que você precisar, independentemente da versão do fornecedor que você tenha implantado originalmente.

Dica: Seu período de suporte “LTS” é aquele definido pelo fornecedor cuja compilação você baixou – e não o que a Oracle diz. A compilação da Microsoft do OpenJDK, o Amazon Corretto, o Azul Zulu e o Eclipse Temurin têm datas de término diferentes para a mesma versão do Java. Verifique a página de ciclo de vida publicada pelo seu fornecedor antes de presumir que ainda tem anos de suporte pela frente.

Fim do ciclo de vida do OpenJDK 11: as datas que realmente importam

O Java 11 foi lançado em setembro de 2018 como a segunda versão LTS após o Java 8. O prazo de suporte varia significativamente dependendo da compilação que você estiver executando — e, como mostra a tabela abaixo, alguns fornecedores estenderam seus prazos muito além do que a maioria das equipes espera.

O panorama é mais variado do que a maioria das equipes imagina. Se você estiver utilizando a versão da Red Hat sem uma assinatura do ELS-1, os patches gratuitos terminaram em 31 de outubro de 2024. Para equipes que gerenciam pilhas de software mais amplas nessa plataforma, acompanhar o cronograma do fim da vida útil do RHEL 8 é igualmente essencial para o planejamento operacional. O Premier Support da Oracle terminou ainda mais cedo, em setembro de 2023. Mas se você estiver usando o Corretto, o Temurin ou o Azul Zulu, ainda pode estar dentro do período de suporte ativo do seu fornecedor. Sua exposição real depende de qual versão você está executando e do nível de atualização dos seus patches, não apenas do número da versão.

Atenção: “Estamos em uma versão com suporte” geralmente significa “baixamos a versão mais recente há seis meses e nunca mais atualizamos desde então”. Os fornecedores do OpenJDK lançam atualizações de patches críticos trimestralmente — se o nível de patch da sua versão tiver mais de 90 dias, você terá vulnerabilidades CVE sem patch, mesmo que sua versão ainda esteja tecnicamente sob suporte.

E quanto ao OpenJDK 8?

O Java 8 tem uma história semelhante, embora seu cronograma tenha se estendido por mais tempo do que a maioria esperava. As atualizações públicas gratuitas da Oracle para o Java 8 terminaram em janeiro de 2019 para usuários comerciais. No entanto, os fornecedores mantiveram suas próprias versões muito além dessa data.

O suporte da Red Hat ao OpenJDK 8 se estende até pelo menos 2026 para assinantes do RHEL, e o Azul, o Amazon Corretto e o Eclipse Temurin continuam fornecendo versões com diferentes níveis de manutenção ativa. No início de 2026, o Java 8 ainda representava uma parcela significativa das cargas de trabalho em produção — em algumas pesquisas, aproximadamente comparável ao Java 11.

A diferença entre o Java 8 e o Java 11 é que o Java 8 já está em território de “extensão” há mais tempo; por isso, as organizações que ainda o utilizam tendem a ser mais conscientes dessa decisão. As equipes que trabalham com o Java 11 geralmente estão apenas no início dessa discussão, muitas vezes porque a data de fim de vida útil (EOL) as pegou de surpresa.

Se você estiver gerenciando cargas de trabalho tanto do Java 8 quanto do Java 11, as considerações são semelhantes. O volume de CVEs que se acumulam ao longo de uma versão LTS de longa duração é preocupante — o histórico de CVEs do Java 8 é um ponto de referência útil para entender o que o Java 11 está prestes a enfrentar sem patches.

O Java 11 e o Java 8 ainda estão por toda parte

Os dados da New Relic — extraídos de centenas de milhares de aplicativos em produção — indicam que, juntos, o Java 11 e o Java 8 representam cerca de 62% das cargas de trabalho em produção, sendo 33% para o Java 11 e 28,8% para o Java 8.

Existem motivos reais para isso, não apenas inércia organizacional. O Java 11 e o Java 8 são versões estáveis e bem compreendidas que alimentam aplicativos web, serviços de back-end, plataformas de middleware e ferramentas internas em praticamente todos os setores. Muitos deles dependem de frameworks com suas próprias restrições de ciclo de vida — se uma plataforma de middleware for certificada apenas para o Java 11, a atualização do ambiente de execução não é uma decisão unilateral que a equipe de operações possa tomar.

Reescrever ou atualizar um aplicativo nem sempre é viável quando ele é essencial para os negócios, está mal documentado ou é mantido por uma equipe que tem metade do tamanho que tinha quando o aplicativo foi desenvolvido. Isso não é um fracasso — é a realidade de como funciona o software corporativo.

O que acontece depois que o suporte da comunidade termina?

No dia seguinte ao EOL, nada de dramático acontece. Suas JVMs continuam funcionando. Seus aplicativos continuam respondendo. Esse é exatamente o problema: o modo de falha é silencioso e só aparece mais tarde como uma vulnerabilidade CVE para a qual não há correção disponível.

Veja o que realmente muda:

• As correções CVE deixam de ser disponibilizadas para a sua versão do Java: Qualquer vulnerabilidade descoberta após o fim do ciclo de vida (EOL) nunca será corrigida em seu ambiente de execução por meio de canais gratuitos – ela se acumula, e sua exposição aumenta a cada nova divulgação.
• As estruturas de conformidade começam a causar atritos:SOC 2, PCI DSS, HIPAA e FedRAMP exigem, todos, um gerenciamento documentado de patches para vulnerabilidades conhecidas. Executar um ambiente de execução em fim de vida (EOL) não causa uma reprovação automática na auditoria, mas defendê-lo se torna cada vez mais difícil.
• A evolução das dependências se acelera: Bibliotecas e frameworks deixam de oferecer suporte a versões mais antigas do Java à medida que seus próprios ecossistemas evoluem; assim, o software em torno do seu ambiente de execução estagnado perde compatibilidade de forma imperceptível.
• As imagens base de contêineres deixam de ser atualizadas: As imagens openjdk:11 no Docker Hub foram descontinuadas bem antes do fim da vida útil (EOL) definido pela comunidade. Se você ainda estiver baixando essas imagens, estará baixando um instantâneo estático que contém vulnerabilidades conhecidas.
• A responsabilidade do fornecedor passa a ser sua: A maioria dos contratos de software empresarial contém cláusulas sobre a execução de software com suporte. Ao utilizar um ambiente de execução em fim de vida útil (EOL), você assume pessoalmente esse risco.

Por que “basta atualizar” é mais difícil do que parece

A recomendação padrão – “atualize para o Java 17 ou 21” – é a resposta certa em uma apresentação de slides, mas a resposta errada para muitas bases de código reais. Veja por que as equipes continuam usando o OpenJDK 11, mesmo sabendo que provavelmente não deveriam.

Dependência de bibliotecas e frameworks

Um número surpreendente de aplicativos Java em produção depende de bibliotecas que não são recompiladas nem testadas com JDKs mais recentes há anos. Ao migrar do Java 11 para o 17, você começa a enfrentar problemas com:

• Foram removidas APIs das quais bibliotecas mais antigas dependiam sem que isso fosse explicitamente indicado
• Encapsulamento mais rigoroso (introduzido no Java 9 e reforçado desde então), que causa incompatibilidade com bibliotecas mais antigas de manipulação de bytecode
• Incompatibilidades em bibliotecas como versões antigas do Lombok, Mockito ou Byte Buddy
• JAXB, JAX-WS e outras APIs do Java EE que foram totalmente removidas do JDK

Imagine uma equipe de engenharia de 20 pessoas no meio de um processo de migração: eles atualizaram o código do aplicativo, as ferramentas de compilação e o pipeline de integração contínua (CI). Então, a biblioteca interna de SSO — cuja última manutenção foi feita por um engenheiro que saiu da empresa há três anos — gera um IllegalAccessError no primeiro teste de integração. Isso significa uma semana de depuração antes que eles decidam criar um fork da biblioteca, e essa é apenas uma dependência.

Conjuntos de aplicativos certificados

Os fornecedores de software empresarial certificam seus produtos para versões específicas do Java. Sistemas de ERP, plataformas bancárias, ferramentas de subscrição de seguros e softwares da área da saúde costumam ter uma matriz de suporte que indica “Java 8 e 11” – e nada mais. A atualização do JDK subjacente invalida o contrato de suporte. Nesse cenário, a atualização do ambiente de execução não é impedida pela complexidade do código, mas sim por uma cláusula contratual.

Custo da migração e tolerância ao risco

As migrações causam problemas — é isso que as equipes aprenderam com cada mudança de versão LTS anterior. Uma migração realista do Java 11 para o 17 em uma base de código não trivial envolve auditar todas as dependências diretas e transitivas (geralmente mais de 200 bibliotecas), atualizar ferramentas de compilação e pipelines de CI, reexecutar conjuntos completos de testes de regressão e de carga, coordenar entre serviços e refatorar em torno de APIs removidas. Para uma equipe que opera 10 serviços, isso representa um quarto do tempo de engenharia. Para uma equipe que opera 200 serviços, é um programa com duração de um ano.

A realidade: Os fornecedores adoram publicar guias de “migração fácil” que mostram uma atualização do Java 8 para o 17 em um vídeo de 30 minutos. Essas demonstrações usam aplicativos Spring Boot simples, com apenas cinco dependências. Sua base de código de produção tem anos de complexidade acumulada, vários forks de bibliotecas internas abandonadas e, provavelmente, pelo menos um JAR cuja origem ninguém conhece. Planeje-se para isso, não para a demonstração.

O que fazer depois que o OpenJDK 11 chegar ao fim do ciclo de vida

Existem três caminhos realistas a seguir, e o caminho certo depende de quanto tempo você realmente tem para realizar a migração.

Suporte estendido ao ciclo de vida

Se você não puder realizar a migração no curto prazo, mas não puder se dar ao luxo de deixar as vulnerabilidades (CVEs) sem correção, o suporte estendido é a solução mais adequada. Grandes fornecedores, como a Oracle e a Red Hat, oferecem planos de suporte estendido pagos com prazos definidos, e provedores independentes preenchem essa lacuna para organizações que precisam de algo mais flexível.

O Suporte de Ciclo de Vida Ilimitado (ELS) da TuxCare para o OpenJDK abrange as versões 6, 7, 8, 11 e 17 — incluindo versões cujo fim de vida útil (EOL) pela comunidade já tenha ocorrido. Ele foi projetado especificamente para equipes que precisam de patches de segurança contínuos sem serem obrigadas a seguir um cronograma de atualização que não conseguem cumprir de forma realista:

• Patches de CVE retroativos para versões do OpenJDK cujo fim de vida útil (EOL) já passou, segundo a comunidade
• Independente do fornecedor – funciona independentemente de você ter implantado originalmente a versão do OpenJDK da Red Hat, o Adoptium, o Corretto ou uma instalação personalizada
• Não é necessário fazer alterações no código do aplicativo
• A cobertura continua pelo tempo que você precisar, e não por um período fixo de dois ou três anos
• Abrange variantes do Enterprise Linux e distribuições baseadas no Debian, incluindo RHEL, CentOS, AlmaLinux, Rocky Linux, Oracle Linux, Debian e Ubuntu.

O ELS da TuxCare para o OpenJDK é uma solução no nível de tempo de execução — ele aplica patches especificamente no ambiente de execução do Java. Se você também estiver executando uma distribuição Linux no fim do ciclo de vida (EOL) (por exemplo, o CentOS 7), a TuxCare oferece um ELS separado para sistemas operacionais que abrange todo o conjunto de pacotes do SO, incluindo o OpenJDK, quando este faz parte desse conjunto. Trata-se de produtos distintos. O ELS para OpenJDK oferece cobertura de tempo de execução independentemente do seu sistema operacional; o ELS para o sistema operacional abrange toda a distribuição. Dependendo da sua situação, você pode precisar de um, do outro ou de ambos.

Se a sua preocupação for exclusivamente o ambiente de execução do Java — mesmo ao executá-lo em um sistema operacional atual e compatível —, o TuxCare ELS para OpenJDK cuida disso sem exigir uma assinatura no nível do sistema operacional.

Migrar para o Java 17 ou o Java 21

Se você dispõe da capacidade técnica necessária e sua pilha de tecnologia permite, a migração para uma versão LTS atual é a solução correta a longo prazo. A adoção do Java 17 atingiu 35% das aplicações em produção em 2024, de acordo com a New Relic, e a taxa de adoção do Java 21 nos primeiros seis meses superou a do Java 17 em quase três vezes.

O Java 17 representa um avanço significativo, embora tenha seu próprio cronograma de suporte que deve ser levado em consideração no planejamento. Saiba mais sobre o fim da vida útil (EOL) do OpenJDK 17 antes de defini-lo como sua meta de longo prazo.

Algumas dicas práticas para começar:

• Correr jdeps --jdk-internals em relação aos JARs do seu aplicativo, para identificar antecipadamente o uso de APIs internas removidas
• Verifique todas as dependências do Maven/Gradle para identificar a versão mais recente compatível com a versão do Java que você deseja utilizar
• Realize a migração por meio de implantações em ambiente de desenvolvimento, teste e canário antes da implementação em toda a frota
• Reserve tempo explicitamente para as surpresas do tipo “descobrimos outra biblioteca” – elas não são hipotéticas

O Java 21 é a melhor opção, se for possível migrar para ele. Ele possui um dos períodos de suporte mais longos ainda disponíveis entre os fornecedores e inclui threads virtuais — o que pode reduzir significativamente a sobrecarga do pool de threads para cargas de trabalho de alta concorrência.

Continuar com o produto em fim de vida útil e aceitar o risco

É isso que muitas equipes estão fazendo discretamente. Se você optar por esse caminho, faça-o de forma consciente:

• Documente a decisão formalmente e obtenha a aprovação da liderança das áreas de segurança e conformidade
• Implementar controles compensatórios (WAF, autoproteção de aplicativos em tempo de execução, políticas de rede mais rigorosas)
• Monitore semanalmente os feeds do CVE para o Java 11 e o Java 8 e avalie cada divulgação em relação à sua exposição real
• Estabeleça um prazo rígido para a migração ou para a adoção do suporte estendido – “vamos resolver isso um dia” é como você acaba ainda usando o Java 11 em 2028

Esse é o caminho mais arriscado e não é sustentável indefinidamente. Mas se a alternativa realista for lançar uma migração parcialmente testada em duas semanas, um período de espera documentado e controlado é, às vezes, a escolha mais justificável. A diferença fundamental está na intencionalidade.

Da prática: As equipes que conduzem as transições de fim de vida útil (EOL) da maneira mais tranquila são aquelas que começaram a se planejar 12 meses antes da data. Se você estiver lendo isso em 2026 e ainda estiver usando o OpenJDK 11 sem um plano, a margem de manobra já terá acabado. Escolha um desses três caminhos ainda neste trimestre.

Seus próximos passos após o fim do ciclo de vida (EOL) do OpenJDK 11

O suporte da comunidade upstream do OpenJDK 11 chegou ao fim no final de 2024, e vários períodos de suporte oferecidos por fornecedores estão chegando ao fim nos próximos anos. Suas JVMs não se importam com essas datas — mas seus auditores, seu CISO e sua equipe de resposta a incidentes vão se importar cada vez mais com elas.

Se for possível migrar, opte pelo Java 21 em vez do Java 17 — o prazo de suporte é mais longo, e os threads virtuais representam uma melhoria significativa para cargas de trabalho de alta concorrência. Se a migração não for viável no momento, mas você precisar de patches de segurança contínuos, o TuxCare ELS para OpenJDK oferece suporte ao Java 8, 11 e outras versões além do fim de vida útil (EOL) em diversos ambientes corporativos baseados em Linux e Debian — vale a pena avaliá-lo antes de sua próxima revisão de conformidade.

Seja qual for o caminho que você escolher, escolha-o de forma consciente. O pior resultado é aquele que ocorre por omissão — permanecer no Java 11 em fim de vida útil (EOL) porque ninguém tomou uma decisão consciente de fazer outra coisa.

Resumo

Nome do artigo

Fim do ciclo de vida do OpenJDK 11: datas, riscos e suas opções (Guia para 2026)

Descrição

Explicação sobre o fim do ciclo de vida do OpenJDK 11: datas importantes, riscos de segurança e suas opções para atualizar ou prorrogar o suporte em 2026.

Autor

Rohan Timalsina

Nome da editora

TuxCare

Logotipo da editora