De que versão do Java preciso? Visão geral para servidores

Num servidor, o Java raramente é um fim em si mesmo. Está lá porque um servidor de Minecraft, um Tomcat, um Jenkins ou um índice de pesquisa o exigem. E é exatamente por isso que a pergunta nunca é "qual é o melhor Java", mas sim "que Java espera esta aplicação concreta, e será que o consigo sequer neste sistema operativo". Este artigo responde às duas coisas: com os calendários de suporte, com uma tabela de disponibilidade que medimos em containers reais e com a prática de manter várias versões em paralelo.

A versão curta: que versão para que finalidade

Se não tiver tempo, a decisão é esta:

• Projeto novo, escolha livre: Java 21. É atualmente a linha LTS com suporte mais alargado, vem empacotada de origem no Debian 13 e em todas as versões atuais do Ubuntu, e praticamente todo o software de servidor recente corre sobre ela.
• Minecraft 1.20.5 até 1.21.11: Java 21. Obrigatório, sem margem de manobra.
• Minecraft 26.1 e mais recente: Java 25.
• Aplicação mais antiga que indica "Java 17" na documentação: use o Java 17, não "17 ou mais recente". Em modloaders e sistemas de plugins, esse "mais recente" muitas vezes não corresponde à verdade.
• Java 8 ou 11: apenas quando uma aplicação antiga o obriga. Ambos pertencem à sua lista de coisas que têm de ser substituídas.
• Java 25: a linha LTS mais recente, faz sentido para deployments novos, mas verifique antes se a sua framework já está oficialmente aprovada para ela.

Para a instalação propriamente dita temos guias próprios: instalar o Java 17 no Debian e instalar o Java 21 no Debian. Este artigo é o mapa que está por cima deles.

O que significa LTS e durante quanto tempo cada versão é mantida

O Java sai numa nova versão principal a cada seis meses. A esmagadora maioria delas está morta ao fim de exatamente seis meses: o Java 22, 23, 24 e 26 deixam de receber atualizações de segurança assim que chega a versão seguinte. Num servidor, não as quer ter.

Interessam exclusivamente as versões LTS (Long Term Support). Desde 2021 saem de dois em dois anos: 8, 11, 17, 21, 25, e a seguir está prevista a Java 29 para setembro de 2027. Só estas linhas recebem atualizações de segurança trimestrais ao longo de vários anos.

Importa distinguir entre a Oracle e as builds livres. Para operação em servidor recorre, por regra, ao OpenJDK do pacote da distribuição ou ao Eclipse Temurin. Ambos são de utilização gratuita, e a manutenção corre aí, em parte, bastante mais tempo do que na licença gratuita da Oracle.

A linha do Java 17 surpreende muita gente: apenas até outubro de 2027. O Java 17 parece novo, mas já é a penúltima geração LTS. Quem monta hoje um sistema para durar três anos faz melhor em planear logo com o 21 ou o 25.

Que versão do Java a sua distribuição tem no próprio repositório

É aqui que falham quase todos os guias que circulam na Internet: escrevem "apt install openjdk-17-jre-headless" e partem do princípio de que isso resulta em todo o lado. Não resulta. Medimos a situação dos pacotes a 27/07/2026 em containers acabados de criar.

Leia as colunas do Debian duas vezes. O Debian 12 conhece exclusivamente o Java 17. O Debian 13 já não conhece o Java 17, em contrapartida tem o 21 e o 25. Ou seja, nas fontes oficiais do Debian não existe uma única versão presente nos dois releases. Quem escreve um script de deploy para correr em bookworm e em trixie não se pode apoiar num único pacote.

Neste aspeto, o Ubuntu é mais simpático: aí as cinco linhas LTS estão lado a lado no repositório, tanto no 22.04 como no 24.04. Se precisar de um sistema onde uma aplicação antiga com Java 8 e um serviço moderno com Java 21 corram ao mesmo tempo, o Ubuntu é o atalho.

Na dúvida, verifique por si em vez de adivinhar:

apt update
apt-cache policy openjdk-21-jre-headless
apt-cache search openjdk-

Se em "Candidato", ou "Candidate" num sistema em inglês, aparecer (none), esse pacote não existe nesta distribuição. Na família Red Hat (AlmaLinux, Rocky, RHEL, Oracle Linux) os pacotes têm outros nomes, e aí a listagem faz-se assim:

dnf list java-\*-openjdk-headless
dnf install -y java-21-openjdk-headless

Para ter a visão de conjunto, use dnf list e não dnf list available. Este último esconde os pacotes já instalados, portanto, depois de instalar o Java 21, o Java 21 deixa de aparecer na lista e acaba por se procurar no sítio errado. A situação na família Red Hat, igualmente medida em containers acabados de criar:

O AlmaLinux 10 fez, portanto, o mesmo corte que o Debian 13 e deixou cair tudo abaixo do 21. Um dnf install java-17-openjdk-headless termina aí com No match for argument.

headless ou não, JRE ou JDK

Num servidor escolha sempre a variante -headless. Prescinde das bibliotecas gráficas e, por isso, não arrasta dependências de X11, o que num servidor root poupa dezenas de pacotes supérfluos. E o -jre-headless chega, desde que se limite a executar ficheiros JAR já prontos. Só quando compila por si próprio, ou quando alguma ferramenta invoca o javac, é que precisa do openjdk-21-jdk-headless.

Na família Red Hat vale a pena, neste ponto, um segundo olhar sobre as dependências. No AlmaLinux 9, o pacote java-21-openjdk-devel arrasta uma cadeia surpreendentemente longa de pacotes gráficos, entre eles webkit2gtk3-jsc, xorg-x11-fonts, xdg-desktop-portal e wireplumber. Num servidor sem interface gráfica, ninguém quer isso. Verifique por isso antes, com dnf install --assumeno, o que vem realmente atrás, e fique-se pelo java-21-openjdk-headless enquanto não tiver de compilar nada.

Minecraft: versão do jogo e versão do Java

O Minecraft é o motivo mais frequente para alguém sequer instalar Java num servidor e, ao mesmo tempo, a área com os requisitos mais rígidos. A correspondência é inequívoca:

Duas notas a este respeito, que faltam na maioria das tabelas. Primeira: com a 26.1, o Minecraft abandonou o antigo esquema 1.x e passou para um esquema anual, ou seja, a 26.1 é a primeira edição do ano de 2026. A 1.21.11 foi a última versão que se contenta com o Java 21.

Segunda: o "ou mais recente" vale para o servidor vanilla. Assim que entram modloaders em jogo, deixa de ser fiável. Um servidor Forge para a 1.20.1 está construído sobre o Java 17, e passá-lo para Java 21 é uma das causas mais frequentes de crashes logo no arranque, apesar de o número ser "maior". Em servidores modded use exatamente a versão que o criador do modpack indica.

A parte prática está nos nossos guias instalar um servidor de Minecraft no Debian e arrancar um servidor de Minecraft automaticamente.

Outras aplicações de servidor e as suas exigências

Para lá do Minecraft valem, em traços gerais, estas regras:

• Apache Tomcat: o 9.0.x corre a partir do Java 8, o 10.1.x exige pelo menos o Java 11, o 11.0.x exige pelo menos o Java 17. Os três ramos atualmente mantidos correm sem problemas em Java 17.
• Elasticsearch e OpenSearch: trazem uma JVM própria. Aí não instale um Java de sistema nem defina um JAVA_HOME global que se sobreponha à JVM fornecida. É uma fonte de erros clássica depois de uma "arrumação" da instalação de Java.
• Jenkins: as versões atuais pressupõem pelo menos o Java 17 e correm em Java 21.
• Keycloak, Kafka, Solr, Nexus: orientam-se pela penúltima LTS de cada momento. Consulte as release notes da versão concreta, porque estes projetos sobem o limite mínimo com regularidade.

Nem todo o software de servidor que se associa ao Java precisa de facto dele. O servidor TeamSpeak 3, por exemplo, é um binário nativo e dispensa a JVM.

Manter várias versões do Java em paralelo e alternar entre elas

No Debian e no Ubuntu pode instalar em simultâneo tantos pacotes OpenJDK quantos quiser. Cada um vai parar a um diretório próprio sob /usr/lib/jvm/ e não se estorvam uns aos outros:

apt install -y openjdk-21-jre-headless openjdk-25-jre-headless
ls /usr/lib/jvm/

O que partilham é exatamente um ficheiro: /usr/bin/java. É um symlink gerido pelo sistema de alternativas. Os candidatos mostram-se assim:

update-alternatives --list java
update-alternatives --display java

Esta forma de escrita, com o nome a seguir a --list, é específica do Debian; na família Red Hat é diferente, e voltamos a isso mais abaixo. A saída de --display é a mais importante das duas. Mostra não só os caminhos, mas também o modo (auto ou manual) e a prioridade de cada entrada. A troca faz-se de forma interativa com update-alternatives --config java e a escolha de um número; em scripts, é preferível fixá-la:

update-alternatives --set java /usr/lib/jvm/java-21-openjdk-amd64/bin/java
java -version

Nunca copie esse caminho de um tutorial alheio, retire-o antes de update-alternatives --list java. O caminho mostrado acima vale para o OpenJDK do pacote da distribuição. Quem seguir a secção sobre o Temurin, mais abaixo, nem sequer tem esse diretório: aí chama-se /usr/lib/jvm/temurin-21-jre-amd64/bin/java, e o comando aborta com alternative path ... doesn't exist.

Se também compilar, o javac tem de ser trocado à parte. É algo que se esquece com facilidade e conduz à situação absurda de se compilar com Java 25 e arrancar com Java 21:

update-alternatives --set javac /usr/lib/jvm/java-21-openjdk-amd64/bin/javac
javac -version

A armadilha que lhe custa noites de sono

Enquanto o java estiver no modo auto, ganha sempre a prioridade mais alta, e a prioridade mais alta pertence à versão instalada mais recente. Se meses depois instalar também o openjdk-25, porque outro serviço precisa dele, o /usr/bin/java salta silenciosamente para o 25 na operação de pacotes seguinte. O seu servidor de Minecraft, que até aí corria em 21, arranca depois do reinício seguinte sobre uma JVM que nunca escolheu.

O update-alternatives --set coloca a entrada em manual e congela-a assim. É esse o verdadeiro propósito do comando. Para voltar ao modo automático:

update-alternatives --auto java

Ainda assim, o caminho mais robusto para serviços é não depender de todo do /usr/bin/java. Indique o caminho completo na sua unit do systemd: a escolha da versão fica fixada por serviço e independente de qualquer troca de alternativas:

ExecStart=/usr/lib/jvm/java-21-openjdk-amd64/bin/java -Xms2G -Xmx4G -jar server.jar nogui

Como se compõe uma unit completa está em criar um serviço systemd. Já agora, é precisamente este caminho absoluto que explica por que razão um serviço às vezes não acompanha uma troca de Java: o update-alternatives pura e simplesmente não lhe toca.

No AlmaLinux, Rocky Linux, RHEL e Oracle Linux a ferramenta chama-se alternatives, e o update-alternatives é aí apenas um symlink para ela. Só que não funciona da mesma maneira: este --list não aceita argumento. Um update-alternatives --list java copiado limita-se a imprimir o texto de ajuda e termina com o código de retorno 2. O correto é uma destas duas linhas:

alternatives --list | grep java
alternatives --display java

Também a saída de --display diverge: em vez de java - auto mode aparece aí java - status is auto. Na família Red Hat os caminhos incluem, além disso, o número de versão completo, algo como /usr/lib/jvm/java-21-openjdk-21.0.11.0.10-1.el9.x86_64, e não a forma curta do Debian java-21-openjdk-amd64. Só o AlmaLinux 10 cria adicionalmente um symlink curto java-21-openjdk.

E o automatismo comporta-se aí de forma diferente do que seria de esperar: depois de instalar o Java 17 ao lado de um Java 21 já existente, no AlmaLinux 9 o alternatives mudou por iniciativa própria o link /usr/bin/java para o 17, ou seja, para a versão mais antiga. Por isso, depois de cada instalação adicional, defina explicitamente alternatives --set java <caminho> e confirme com java -version.

Quando a distribuição não tem a versão: Temurin

Para as lacunas da tabela acima há uma resposta limpa: o Eclipse Temurin, da Adoptium, fornece temurin-8 até temurin-26 para trixie, bookworm, noble e jammy. Assim obtém o Java 21 também no Debian 12 e o Java 17 também no Debian 13, sem PPAs de terceiros nem tarballs copiados à mão para /opt.

Tenha em conta que o apt-key está descontinuado. A chave pertence a /etc/apt/keyrings/ e é referenciada através de signed-by:

apt install -y wget gnupg ca-certificates apt-transport-https
install -d -m 0755 /etc/apt/keyrings
wget -qO - https://packages.adoptium.net/artifactory/api/gpg/key/public | gpg --dearmor | tee /etc/apt/keyrings/adoptium.gpg > /dev/null
echo "deb [signed-by=/etc/apt/keyrings/adoptium.gpg] https://packages.adoptium.net/artifactory/deb $(awk -F= '/^VERSION_CODENAME/{print$2}' /etc/os-release) main" | tee /etc/apt/sources.list.d/adoptium.list
apt update
apt install -y temurin-21-jre

Os pacotes Temurin registam-se igualmente no sistema de alternativas, aparecem portanto em update-alternatives --display java e podem ser misturados com os pacotes OpenJDK da distribuição. Os seus diretórios ficam em /usr/lib/jvm/temurin-21-jre-amd64 ou com nome semelhante.

Mensagens de erro na íntegra e o que significam

E: Unable to locate package openjdk-17-jre-headless
A versão não existe nesta distribuição. No Debian 13 esse é o caso normal para o Java 8, 11 e 17. Não é gralha nem falta de apt update: use o Temurin ou outra versão.

java.lang.UnsupportedClassVersionError: ... has been compiled by a more recent version of the Java Runtime (class file version 65.0), this version of the Java Runtime only recognizes class file versions up to 61.0
O clássico. A aplicação foi construída para uma JVM mais recente do que aquela com que arrancou. Os números traduzem-se assim:

65.0 contra 61.0 quer dizer, em bom português: o software quer Java 21, mas o que está a correr é o Java 17. Em servidores de Minecraft a partir da 1.20.5 vê este erro muitas vezes embrulhado como Error: LinkageError occurred while loading main class net.minecraft.bundler.Main, e a causa real está então na linha abaixo.

java: command not found
Não há nenhuma JVM instalada, ou descompactou apenas um diretório JDK para /opt sem o registar. Verifique com ls /usr/lib/jvm/. Se aí houver diretórios mas faltar o /usr/bin/java, registe a entrada a posteriori:

update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-21-openjdk-amd64/bin/java 2111

update-alternatives: error: no alternatives for java
O sistema de alternativas não conhece candidato nenhum. Acontece quando o Java foi instalado à mão. A correção é a mesma de cima.

update-alternatives: error: alternative path /usr/lib/jvm/... doesn't exist
Definiu um caminho que entretanto desapareceu, tipicamente depois de uma desinstalação. Repare que os caminhos do Debian contêm a arquitetura: java-21-openjdk-amd64, não java-21-openjdk.

O serviço corre, mas na versão errada.
Muito provavelmente há um caminho absoluto na unit do systemd, ou a unit define um JAVA_HOME próprio. Ambos se sobrepõem ao update-alternatives sem qualquer aviso.

O servidor arranca, mas morre ao fim de segundos sem mensagem percetível.
Em aplicações Java isso muitas vezes não é um problema de versão, mas falta de memória: o kernel termina o processo quando o -Xmx é escolhido maior do que a RAM livre. A este propósito servem os nossos artigos configurar swap contra Out of Memory e libertar espaço com o disco cheio no Linux.

Como confirmar que está mesmo a correr a versão certa

A primeira verificação é trivial, mas faça-a mesmo assim depois de cada troca:

java -version

A saída tem de indicar a versão principal esperada, por exemplo openjdk version "21.0.11". A segunda verificação é a mais elucidativa, porque mostra o caminho realmente resolvido e, com ele, se apanhou o Temurin ou o OpenJDK da distribuição:

readlink -f "$(command -v java)"

Use aqui conscientemente command -v e não which. O which é um programa externo e, na instalação mínima do AlmaLinux 9 e 10, do Rocky Linux 9 e do Oracle Linux 9, nem sequer vem incluído. A variante com which termina aí com which: command not found, seguido de readlink: missing operand. O command -v é um builtin da shell e funciona em todas as distribuições referidas.

E se quiser saber o que a própria JVM pensa sobre a casa onde vive, porque alguma aplicação avalia o JAVA_HOME:

java -XshowSettings:properties -version

Na saída interessam o java.home e o java.version. Se o java.home divergir do que esperava, há algures um JAVA_HOME definido, e é esse que ganha.

Num serviço em execução, no fim só conta o que o próprio processo utiliza. Isso lê-se diretamente na lista de processos, onde está o caminho completo da JVM com que arrancou:

ps -eo pid,args | grep '[j]ava'

Se aí vir /usr/lib/jvm/java-21-openjdk-amd64/bin/java, o assunto está resolvido. Se vir um java despido, o seu serviço está pendurado no symlink das alternativas e muda com ele. Para um serviço em produção, essa é a pior das duas variantes.

Se estiver de qualquer forma a montar um servidor de raiz, vale a pena olhar antes para a nossa lista de verificação para servidores root novos: o Java pertence ao fim dessa lista, não ao início, porque só com acesso SSH a funcionar, firewall e fuso horário definidos é que procurar erros numa JVM se torna minimamente agradável.

Em resumo

O Java 21 é hoje a resposta padrão, o Java 25 a resposta virada para o futuro, o Java 17 a que está a terminar, e o Java 8 e o 11 são dívida de migração. Decisivo, porém, não é o número por si só, mas a combinação entre aplicação e distribuição: o Debian 12 dá-lhe apenas o 17, o Debian 13 apenas o 21 e o 25, o Ubuntu dá-lhe tudo. Onde o pacote falta, o Temurin preenche a lacuna. E assim que houver mais do que uma versão na máquina vale a regra: update-alternatives --set em vez do automatismo e, nas units do systemd, melhor logo o caminho absoluto.