Trauma Zer0
PT

O Java 21 mudou de licença: em que máquinas está a correr?

Desde 20 de outubro, o Oracle JDK 21 atualizado exige subscrição em produção. Antes de pagar ou migrar, saiba em que máquinas corre e quem o usa.

Diagrama com três cartões brancos dentro de um grupo tracejado rotulado 'no parque': Oracle JDK 21 na versão de setembro, gratuita e sem correções novas; Oracle JDK 21 na versão de outubro, com ponto de alerta, licença OTN que exige licença paga em produção; e Oracle JDK 25, gratuito até 2028. Uma seta leva a um cartão azul do servidor da empresa com versão, uso em 90 dias e origem de cada máquina, e a decisão entre remover, migrar ou licenciar.

Em muitas empresas, o Java entrou no parque sem pedir licença a ninguém. Chegou com uma ferramenta de desenvolvimento, com o cliente de um sistema antigo ou com um instalador que alguém transferiu numa tarde de suporte.

Desde 20 de outubro de 2026, ignorar esta história ficou mais caro. As atualizações do Oracle JDK 21 deixaram de sair sob os termos gratuitos e passaram para uma licença que exige subscrição paga para uso em produção.

A pergunta a que a equipa de TI tem de responder agora não é se vai pagar. É mais básica: em que máquinas está instalado o Oracle JDK 21, em que versão, e quem o usa de facto.

O que mudou a 20 de outubro

A Oracle avisou a 14 de agosto, no blogue oficial do Java: as atualizações do JDK 21 publicadas até setembro de 2026 continuariam sob os termos gratuitos (NFTC, No-Fee Terms and Conditions). A partir da atualização crítica de outubro, passariam para a licença OTN.

A licença OTN continua a permitir uso pessoal, desenvolvimento, testes e demonstração. Para correr as versões novas em produção, a Oracle aponta a Java SE Universal Subscription, que desde 2023 é contada pelo total de trabalhadores da empresa, e não pelo número de máquinas com Java.

Quem quiser manter um JDK gratuito da Oracle tem de passar para o JDK 25, que a própria Oracle mantém sob os termos gratuitos até 2028. A alternativa é mudar para uma distribuição OpenJDK de outro fornecedor.

O pormenor que apanha muitas equipas: a licença vale por versão. A máquina que ficou na versão de setembro continua coberta pelos termos gratuitos, mas deixa de receber correções. A mesma máquina, ao receber a versão de outubro, passa a correr um Java sob a licença paga.

A atualização automática que protege a máquina pode ser a mesma que lhe muda a licença.

Porque é que o Java é tão difícil de encontrar

A auditoria de Java não é uma hipótese distante. No inquérito State of Java 2026 da Azul, com 2.039 profissionais de cinco continentes, 21% afirmaram já ter passado por uma auditoria de Java da Oracle. O mesmo inquérito mostra 81% a migrar, ou a planear migrar, pelo menos parte do Java da Oracle para outra distribuição OpenJDK.

A Azul vende uma distribuição OpenJDK, o que convém ter presente ao ler os números. Mas migrar ou subscrever exige o mesmo passo prévio: saber onde está o Java. E ele esconde-se de quatro formas.

Instalado por quem não é da TI

Programadores, analistas de dados, fornecedores de passagem. O Oracle JDK é transferido diretamente do site, sem pedido à equipa de TI, e fica lá depois de o projeto terminar. O Tz0 Inventory lista todos os programas instalados em cada máquina, com versão, data e origem, e mostra o que entrou no parque nas últimas semanas.

Várias versões na mesma máquina

É comum encontrar o Java 8, o 17 e o 21 lado a lado, cada um deixado por um sistema diferente. Cada versão tem a sua regra de licença, e a que pesa na conta é a que está em uso. No inventário, cada versão aparece numa linha própria, máquina a máquina.

Dentro de outro programa

Muitas aplicações trazem o seu próprio Java na pasta de instalação. Este caso tem de ser confirmado com o fornecedor da aplicação, que costuma responder pela licença do que incluiu. Convém pedir essa resposta por escrito, antes da auditoria.

No servidor, longe da vista

Servidor aplicacional, máquina de integração, tarefa agendada. O Java de produção vive mais no servidor do que na secretária do utilizador. O agente do Tz0 Inventory é o mesmo em desktop, portátil e servidor, Windows ou Linux, e tudo entra no mesmo retrato do parque.

Três números antes de qualquer decisão

Com o retrato na mão, a decisão fica mais pequena do que parecia. Três números costumam bastar:

  • Instalado: quantas máquinas têm Oracle JDK, de que versão, e quantas já receberam versões publicadas depois de 20 de outubro.
  • Usado: quantas abriram o Java nos últimos 90 dias. Uma máquina sem uso é candidata a remover, não a licenciar.
  • Em produção: que servidores e máquinas correm sistemas de negócio sobre ele, e não apenas testes ou desenvolvimento.

O Tz0 Inventory mostra as horas de uso de cada programa e as máquinas por escalão de uso nos últimos 90 dias, programa a programa. É a diferença entre negociar com a lista do fabricante e negociar com a sua.

Se a carta de auditoria chegar, o mesmo módulo cruza o que está instalado com o que foi comprado e gera o relatório para a auditoria do fabricante, sem correrias de véspera. A lógica é a de qualquer auditoria de licenças: instalado não é o mesmo que usado.

Ficar parado também custa

A saída mais tentadora é congelar o JDK 21 na última versão gratuita. Tem prazo de validade: cada mês sem atualização é um mês com falhas conhecidas por corrigir, na máquina do programador ou no servidor do sistema de gestão.

O Tz0 Deploy mostra a exposição a falhas conhecidas em máquina-dias e aponta o pacote de maior risco. Com esse número em cima da mesa, o congelamento deixa de ser uma poupança invisível e passa a ser um risco medido.

O guião já é conhecido. No fim do suporte do Office 2021, a data era pública e a lista de máquinas afetadas, não. Com o Java, é igual.

Se a decisão for migrar para o JDK 25 ou para um OpenJDK, a mudança tem de chegar a todas as máquinas, também à que estava desligada nesse dia. O Tz0 Deploy instala e desinstala em silêncio, com janela agendada por destino e controlo de largura de banda, e mostra quem instalou, quem falhou e o que foi reagendado.

O mesmo módulo assinala o programa que corre em versões diferentes no parque, candidato natural a uniformizar, e permite remover em lote o que ficou fora do catálogo aprovado. Antes de remover, teste: um sistema antigo depende, por vezes, de uma versão específica.

Como o Trauma Zer0 ajuda

  • Ninguém sabe onde está o Oracle JDK → inventário de software com versão, data e origem no Tz0 Inventory, em desktop, portátil e servidor → a lista sai da consola, e não de um questionário às áreas.
  • Licença calculada sobre o instalado → horas de uso e escalões de uso a 90 dias por programa → só entra na conta o Java que alguém usa de facto.
  • Carta de auditoria do fabricante → cruzamento do instalado com o comprado e relatório pronto para auditoria → a resposta sai com os seus números, datados.
  • Mudança de versão em centenas de máquinas → instalação e remoção silenciosas, janela agendada, controlo de largura de banda e verificação no Tz0 Deploy → a migração chega a todas, também às que estavam desligadas.
  • Versão congelada com falha conhecida → exposição em máquina-dias e pacote de maior risco no Tz0 Deploy → a equipa vê o risco que o congelamento acumula.

Tudo isto corre instalado na infraestrutura do cliente. A lista de software de cada máquina, que é exatamente o que uma auditoria pede, fica no servidor da própria empresa e não sai para a nuvem.

Se a carta chegasse amanhã, que lista enviaria?

A mudança da Oracle tem data e regra escritas. O que falta na maioria das empresas é a outra metade: a lista das máquinas, com versão e uso, feita antes de alguém a pedir.

Conheça o Tz0 Inventory e o Tz0 Deploy e agende uma demonstração com o seu parque. Se preferir testar no ambiente real, peça uma avaliação do Trauma Zer0.

Quer ver isso funcionando no seu parque?