¿Qué versión de Java necesito? Guía para servidores

En un servidor, Java rara vez es un fin en sí mismo. Está ahí porque lo exige un servidor de Minecraft, un Tomcat, un Jenkins o un índice de búsqueda. Justo por eso la pregunta nunca es "¿cuál es el mejor Java?", sino "¿qué Java espera esta aplicación concreta y puedo conseguirlo en este sistema operativo?". Este artículo responde a las dos cosas: con los calendarios de soporte, con una tabla de disponibilidad que hemos comprobado en contenedores reales y con la práctica de mantener varias versiones en paralelo.

La versión corta: qué versión para qué uso

Si tienes prisa, esta es la decisión:

• Proyecto nuevo, elección libre: Java 21. Es la línea LTS con mayor soporte hoy en día, viene ya empaquetada en Debian 13 y en todas las versiones actuales de Ubuntu, y prácticamente cualquier software de servidor actual funciona sobre ella.
• Minecraft 1.20.5 hasta 1.21.11: Java 21. Obligatorio, sin margen.
• Minecraft 26.1 y posteriores: Java 25.
• Aplicación antigua cuya documentación dice "Java 17": usa Java 17, no "17 o posterior". Con los cargadores de mods y los sistemas de plugins, ese "posterior" muchas veces no se cumple.
• Java 8 u 11: solo si una aplicación heredada te obliga. Ambos pertenecen a tu lista de cosas que hay que sustituir.
• Java 25: la línea LTS más reciente, razonable para despliegues nuevos, pero comprueba antes si tu framework ya está aprobado oficialmente para ella.

Para la instalación en sí tenemos guías propias: instalar Java 17 en Debian e instalar Java 21 en Debian. Este artículo es el mapa que las ordena.

Qué significa LTS y durante cuánto tiempo se mantienen las versiones

Java publica una nueva versión principal cada seis meses. La gran mayoría muere justo a los seis meses: Java 22, 23, 24 y 26 dejan de recibir actualizaciones de seguridad en cuanto llega la siguiente. En un servidor no las quieres.

Solo interesan las versiones LTS (Long Term Support). Desde 2021 salen cada dos años: 8, 11, 17, 21, 25, y la siguiente, Java 29, está prevista para septiembre de 2027. Únicamente estas líneas reciben actualizaciones de seguridad trimestrales durante años.

Conviene distinguir entre Oracle y las compilaciones libres. Para uso en servidor lo habitual es recurrir a OpenJDK del paquete de la distribución o a Eclipse Temurin. Ambos se pueden usar de forma gratuita, y en algunos casos su mantenimiento se prolonga bastante más que el de la licencia gratuita de Oracle.

La fila de Java 17 sorprende a mucha gente: solo hasta octubre de 2027. Java 17 parece reciente, pero ya es la penúltima generación LTS. Si hoy montas un sistema pensado para durar tres años, mejor planifícalo directamente con 21 o 25.

Qué versión de Java trae tu distribución en su propio repositorio

Aquí es donde fallan casi todos los tutoriales de internet: escriben "apt install openjdk-17-jre-headless" y dan por hecho que funciona en todas partes. No es así. Comprobamos la situación de los paquetes el 27/07/2026 en contenedores recién creados.

Lee las columnas de Debian dos veces. Debian 12 solo conoce Java 17. Debian 13 ya no conoce Java 17, pero sí la 21 y la 25. En las fuentes oficiales de Debian no hay, por tanto, ni una sola versión presente en las dos releases. Si escribes un script de despliegue que debe funcionar en bookworm y en trixie, no puedes fiarte de un único paquete.

Ubuntu resulta más cómodo en este aspecto: allí las cinco líneas LTS conviven en el repositorio, tanto en 22.04 como en 24.04. Si necesitas un sistema donde una aplicación heredada con Java 8 y un servicio moderno con Java 21 funcionen a la vez, Ubuntu es el atajo.

En caso de duda, compruébalo tú mismo en lugar de adivinar:

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

Si en "Candidato", o "Candidate" en un sistema en inglés, aparece (none), ese paquete no existe en esta distribución. En la familia Red Hat (AlmaLinux, Rocky, RHEL, Oracle Linux) los paquetes se llaman de otra forma, allí los listas así:

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

Para tener la visión general usa dnf list y no dnf list available. Este último oculta los paquetes ya instalados, así que después de instalar Java 21 esa versión desaparece de la lista y acabas buscando en el sitio equivocado. La situación en la familia Red Hat, comprobada también en contenedores recién creados:

AlmaLinux 10 ha hecho, por tanto, el mismo corte que Debian 13 y ha descartado todo lo anterior a la 21. Un dnf install java-17-openjdk-headless termina allí con No match for argument.

headless o no, JRE o JDK

En un servidor usa siempre la variante -headless. Prescinde de las bibliotecas gráficas y por eso no arrastra dependencias de X11, lo que en un servidor root ahorra decenas de paquetes innecesarios. Y con -jre-headless basta mientras solo ejecutes archivos JAR ya compilados. Únicamente cuando compilas tú mismo o cuando alguna herramienta llama a javac necesitas openjdk-21-jdk-headless.

En la familia Red Hat merece la pena mirar dos veces las dependencias. En AlmaLinux 9, el paquete java-21-openjdk-devel arrastra una cadena sorprendentemente larga de paquetes gráficos, entre ellos webkit2gtk3-jsc, xorg-x11-fonts, xdg-desktop-portal y wireplumber. En un servidor sin entorno gráfico eso no interesa. Comprueba por eso antes con dnf install --assumeno qué se instalaría realmente y quédate con java-21-openjdk-headless mientras no tengas que compilar nada.

Minecraft: versión del juego frente a versión de Java

Minecraft es el motivo más frecuente por el que alguien lleva Java a un servidor y, a la vez, el ámbito con los requisitos más estrictos. La correspondencia es inequívoca:

Dos apuntes que faltan en casi todas las tablas. Primero: con la 26.1, Minecraft abandonó el antiguo esquema 1.x y pasó a un esquema anual, así que 26.1 es la primera entrega del año 2026. La 1.21.11 fue la última versión que se conforma con Java 21.

Segundo: ese "o posterior" vale para el servidor vanilla. En cuanto entran en juego los cargadores de mods, deja de ser fiable. Un servidor Forge para 1.20.1 está compilado sobre Java 17, y ponerlo en Java 21 es una de las causas más habituales de fallos justo al arrancar, aunque el número sea "mayor". En servidores con mods usa exactamente la versión que indique el autor del modpack.

La puesta en práctica está en nuestras guías instalar un servidor de Minecraft en Debian y arrancar un servidor de Minecraft automáticamente.

Otras aplicaciones de servidor y sus exigencias

Más allá de Minecraft, estas son a grandes rasgos las reglas:

• Apache Tomcat: 9.0.x funciona a partir de Java 8, 10.1.x exige como mínimo Java 11 y 11.0.x exige como mínimo Java 17. Las tres ramas con mantenimiento activo funcionan sin problemas sobre Java 17.
• Elasticsearch y OpenSearch: traen su propia JVM. No instales ahí un Java del sistema ni definas un JAVA_HOME global que sobrescriba la JVM incluida. Es una fuente de errores clásica después de "ordenar" la instalación de Java.
• Jenkins: las versiones actuales requieren como mínimo Java 17 y funcionan sobre Java 21.
• Keycloak, Kafka, Solr, Nexus: se guían por la penúltima LTS de cada momento. Consulta las notas de la versión concreta, porque estos proyectos suben el mínimo con regularidad.

No todo el software de servidor que se asocia con Java necesita realmente uno. El servidor de TeamSpeak 3, por ejemplo, es un binario nativo y se las arregla sin JVM.

Mantener varias versiones de Java en paralelo y cambiar entre ellas

En Debian y Ubuntu puedes instalar a la vez tantos paquetes de OpenJDK como quieras. Cada uno acaba en su propio directorio dentro de /usr/lib/jvm/ y no se estorban entre sí:

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

Lo único que comparten es un archivo: /usr/bin/java. Es un symlink que gestiona el sistema de alternativas. Los candidatos se muestran así:

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

Esta sintaxis, con el nombre detrás de --list, es específica de Debian; en la familia Red Hat es distinta, y más abajo lo vemos. La salida de --display es la más valiosa de las dos. No solo muestra las rutas, sino también el modo (auto o manual) y la prioridad de cada entrada. El cambio se hace de forma interactiva con update-alternatives --config java y un número de selección, aunque en scripts es mejor dejarlo fijo:

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

No copies nunca esa ruta de un tutorial ajeno, sácala de update-alternatives --list java. La ruta mostrada arriba vale para el OpenJDK del paquete de la distribución. Quien siga la sección de Temurin más abajo no tendrá ese directorio: allí se llama /usr/lib/jvm/temurin-21-jre-amd64/bin/java, y el comando aborta con alternative path ... doesn't exist.

Si además compilas, hay que cambiar javac por separado. Es algo que se olvida con frecuencia y lleva a la situación absurda de compilar con Java 25 y arrancar con Java 21:

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

La trampa que te cuesta una noche

Mientras java esté en modo auto, gana siempre la prioridad más alta, y la prioridad más alta la tiene la versión instalada más reciente. Así que si meses después añades openjdk-25 porque otro servicio lo necesita, /usr/bin/java saltará en silencio a la 25 en la siguiente operación de paquetes. Tu servidor de Minecraft, que hasta entonces funcionaba con la 21, arrancará tras el siguiente reinicio sobre una JVM que nunca elegiste.

update-alternatives --set pone la entrada en manual y con ello la congela. Ese es el verdadero propósito del comando. Para volver al modo automático:

update-alternatives --auto java

Aun así, la vía más robusta para los servicios es no depender en absoluto de /usr/bin/java. Indica la ruta completa en tu unidad de systemd: entonces la elección de versión queda fijada por servicio e independiente de cualquier cambio en las alternativas:

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

Cómo queda una unidad así al completo lo explicamos en crear un servicio de systemd. Por cierto, esa misma ruta absoluta es también el motivo por el que a veces un servicio no acompaña al cambio de Java: update-alternatives sencillamente no la toca.

En AlmaLinux, Rocky Linux, RHEL y Oracle Linux la herramienta se llama alternatives, y allí update-alternatives es solo un symlink hacia ella. Pero no funciona igual: ese --list no acepta argumentos. Un update-alternatives --list java copiado tal cual imprime allí únicamente el texto de ayuda y termina con el código de retorno 2. Lo correcto es una de estas dos líneas:

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

La salida de --display también difiere: en lugar de java - auto mode aparece java - status is auto. Además, en la familia Red Hat las rutas llevan el número de versión completo, por ejemplo /usr/lib/jvm/java-21-openjdk-21.0.11.0.10-1.el9.x86_64, y no la forma corta de Debian java-21-openjdk-amd64. Solo AlmaLinux 10 crea además un symlink corto java-21-openjdk.

Y el automatismo se comporta allí de forma distinta a lo que uno espera: tras instalar Java 17 junto a un Java 21 ya presente, en AlmaLinux 9 alternatives cambió por su cuenta el enlace /usr/bin/java a la 17, es decir, a la versión más antigua. Por eso, después de cada instalación adicional, fija explícitamente alternatives --set java <ruta> y compruébalo con java -version.

Cuando la distribución no tiene la versión: Temurin

Para los huecos de la tabla anterior hay una respuesta limpia: Eclipse Temurin, de Adoptium, ofrece de temurin-8 a temurin-26 para trixie, bookworm, noble y jammy. Así consigues Java 21 también en Debian 12 y Java 17 también en Debian 13, sin PPA de terceros ni tarballs copiados a mano en /opt.

Ten en cuenta que apt-key está descatalogado. La clave va en /etc/apt/keyrings/ y se referencia mediante 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

Los paquetes de Temurin también se registran en el sistema de alternativas, así que aparecen en update-alternatives --display java y se pueden mezclar con los paquetes de OpenJDK de la distribución. Sus directorios están en /usr/lib/jvm/temurin-21-jre-amd64 o rutas con nombres similares.

Mensajes de error literales y qué significan

E: Unable to locate package openjdk-17-jre-headless
Esa versión no existe en esta distribución. En Debian 13 es lo normal con Java 8, 11 y 17. No es una errata ni falta un apt update: usa Temurin u otra versión.

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
El clásico. La aplicación está compilada para una JVM más reciente que la que has arrancado. Los números se traducen así:

Así que 65.0 frente a 61.0 significa, en claro: el software quiere Java 21 y tú tienes en marcha Java 17. En servidores de Minecraft a partir de 1.20.5 verás este fallo a menudo envuelto como Error: LinkageError occurred while loading main class net.minecraft.bundler.Main, y la causa real aparece entonces en la línea de debajo.

java: command not found
No hay ninguna JVM instalada, o solo has descomprimido un directorio de JDK en /opt sin registrarlo. Comprueba ls /usr/lib/jvm/. Si allí hay directorios pero falta /usr/bin/java, registra la entrada después:

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

update-alternatives: error: no alternatives for java
El sistema de alternativas no conoce ningún candidato. Ocurre cuando Java se instaló a mano. La solución es la misma que arriba.

update-alternatives: error: alternative path /usr/lib/jvm/... doesn't exist
Has fijado una ruta que ya no existe, normalmente tras una desinstalación. Ten presente que las rutas de Debian incluyen la arquitectura: java-21-openjdk-amd64, no java-21-openjdk.

El servicio funciona, pero con la versión equivocada.
Lo más probable es que en la unidad de systemd haya una ruta absoluta, o que la unidad defina su propio JAVA_HOME. Las dos cosas se imponen a update-alternatives sin ningún aviso.

El servidor arranca, pero muere a los pocos segundos sin un mensaje comprensible.
En aplicaciones Java esto no suele ser un problema de versión, sino de falta de memoria: el kernel termina el proceso cuando -Xmx se ha elegido mayor que la RAM libre. Para eso encajan nuestros artículos configurar swap contra Out of Memory y liberar espacio con el disco lleno en Linux.

Cómo reconocer que de verdad está corriendo la versión correcta

La primera comprobación es trivial, pero hazla igualmente después de cada cambio:

java -version

La salida debe indicar la versión principal esperada, por ejemplo openjdk version "21.0.11". La segunda comprobación es la más elocuente, porque muestra la ruta realmente resuelta y con ello también si has acabado con Temurin o con el OpenJDK de la distribución:

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

Usa aquí a propósito command -v y no which. which es un programa externo y en la instalación mínima de AlmaLinux 9 y 10, Rocky Linux 9 y Oracle Linux 9 ni siquiera viene incluido. La variante con which termina allí con which: command not found, seguido de readlink: missing operand. command -v es un builtin de la shell y funciona en todas las distribuciones mencionadas.

Y si quieres saber qué piensa la propia JVM sobre su casa, porque alguna aplicación evalúa JAVA_HOME:

java -XshowSettings:properties -version

De la salida interesan java.home y java.version. Si java.home se desvía de lo que esperabas, hay algún JAVA_HOME definido en alguna parte y ese es el que gana.

En un servicio en marcha, al final solo cuenta lo que usa el propio proceso. Eso lo lees directamente en la lista de procesos, donde figura la ruta completa de la JVM con la que arrancó:

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

Si ves ahí /usr/lib/jvm/java-21-openjdk-amd64/bin/java, asunto resuelto. Si ves un java a secas, tu servicio cuelga del symlink de alternativas y cambia con él. Para un servicio en producción esa es la peor de las dos variantes.

Si de todos modos estás montando un servidor desde cero, antes merece la pena echar un vistazo a nuestra lista de comprobación para servidores root nuevos: Java va al final de esa lista, no al principio, porque solo con el acceso SSH, el firewall y la zona horaria funcionando resulta llevadero buscar fallos en una JVM.

En resumen

Java 21 es hoy la respuesta estándar, Java 25 la que mira al futuro, Java 17 la que se va retirando, y Java 8 y 11 son deuda de migración. Lo decisivo, sin embargo, no es el número por sí solo, sino la combinación de aplicación y distribución: Debian 12 te da solo la 17, Debian 13 solo la 21 y la 25, Ubuntu te lo da todo. Donde falte el paquete, Temurin cubre el hueco. Y en cuanto haya más de una versión en la máquina, la regla es clara: update-alternatives --set en lugar del automatismo y, en las unidades de systemd, mejor directamente la ruta absoluta.