Fin de la vida útil de OpenJDK 11: fechas, riesgos y opciones disponibles (Guía para 2026)

Principales conclusiones

• El soporte gratuito para los parches de seguridad de OpenJDK 11 finalizó a finales de 2024; si no has contratado el soporte ampliado, todas las vulnerabilidades CVE detectadas desde entonces siguen sin estar parcheadas en tu entorno de ejecución.
• La fecha real de fin de vida útil depende de la versión del proveedor que utilices, no de una fecha única para toda la comunidad.
• Actualizar a Java 17 o 21 es la decisión más acertada a largo plazo, pero la dependencia de las bibliotecas y las pilas de aplicaciones certificadas hacen que resulte más complicado de lo que parece.
• El soporte de ciclo de vida ampliado que ofrecen los proveedores o terceros como TuxCare te permite mantener OpenJDK 11 actualizado con los parches mientras planificas la migración según tu propio calendario.

Si actualmente utilizas OpenJDK 11 en entorno de producción, ya has pasado el punto de no retorno. Los parches gratuitos de la comunidad dejaron de publicarse a finales de 2024, y todas las vulnerabilidades CVE publicadas desde entonces han quedado sin corregir en tu entorno de ejecución, a menos que alguien haya pagado por ello.

El fin del ciclo de vida de OpenJDK 11 ya no es algo que debas tener en cuenta para tus planes: ya ha ocurrido, y tu nivel de seguridad se ha ido deteriorando poco a poco a causa de ello. Esta guía repasa las fechas concretas, los cambios que se producirán cuando finalice el soporte de la comunidad y las opciones realistas disponibles cuando «basta con actualizar a Java 17» no sea una frase que puedas llevar a cabo este trimestre.

Resumen del ciclo de vida de OpenJDK

OpenJDK no cuenta con un ciclo de vida de soporte único y unificado, y eso es lo primero que plantea dificultades a los equipos.

El proyecto OpenJDK original solo se compromete a ofrecer seis meses de actualizaciones por cada versión. El resto de plazos que hayas visto provienen de proveedores derivados: Red Hat, Oracle, Amazon, Azul, Microsoft, Eclipse Adoptium. Cada uno de ellos distribuye su propia versión y establece su propia fecha de fin de vida útil.

Esa distinción es más importante de lo que la mayoría de la gente cree. Los términos «fin de vida útil» y «fin del soporte» se utilizan indistintamente hasta que aparece un CVE, y entonces, de repente, la diferencia cobra una enorme importancia. El «fin de vida útil» suele significar «no habrá más actualizaciones gratuitas por parte de este proveedor». El «fin del soporte» significa «no hay ayuda disponible en ningún sitio, ni de pago ni gratuita». En el caso de OpenJDK, puedes llegar al EOL con tu proveedor actual y seguir encontrando soporte de pago en otro lugar. Ese es precisamente el objetivo de los programas de soporte ampliado de los proveedores y de terceros.

Aquí tienes un resumen de lo que te ofrece cada fase del ciclo de vida:

Es importante saber que: La etiqueta «LTS» en Java 8, 11, 17, 21 y 25 es una convención de los proveedores, no un compromiso de OpenJDK. Oracle la inició; el resto del ecosistema la siguió. El proyecto en sí avanza cada seis meses, independientemente de lo que haya en tu servidor.

Tipos de versiones de OpenJDK

OpenJDK se lanza cada seis meses, pero los proveedores tratan las versiones de forma muy diferente dependiendo de si son LTS o no.

Lanzamientos LTS

Las versiones LTS son aquellas que los proveedores se comprometen a mantener durante años. Java 8, 11, 17, 21 y 25 son las versiones LTS actuales. Estas versiones reciben parches de seguridad retroactivos, correcciones de errores y actualizaciones trimestrales de parches críticos de los principales proveedores. Si tienes algo en producción, lo más probable es que quieras una versión LTS; precisamente para eso existen.

El soporte técnico de la comunidad suele incluir parches de seguridad y correcciones de errores gratuitos, pero finaliza en la fecha de fin de vida útil (EOL) establecida para cada versión. A partir de ese momento, las actualizaciones solo están disponibles a través de programas de soporte técnico ampliado específicos del proveedor o de terceros.

Más allá de la comunidad OpenJDK, los proveedores y las distribuciones ofrecen sus propias versiones y calendarios de soporte para las versiones de OpenJDK. Estos calendarios también varían, y comprender las diferencias clave entre OpenJDK y Oracle JDK puede ayudarte a elegir la distribución adecuada para tu estrategia de soporte a largo plazo.

Versiones sin LTS

Las versiones que no son LTS (Java 9, 10, 12, 13, 14, 15, 16, 18, 19, 20, 22, 23, 24 y 26) reciben actualizaciones durante seis meses y, a continuación, dejan de recibir soporte activo. Están pensadas para desarrolladores que desean acceder antes a las nuevas funciones, no para entornos de producción. Según el informe «State of the Java Ecosystem 2024» de New Relic, menos del 2 % de las aplicaciones en producción ejecutan una versión no LTS, lo cual tiene sentido, ya que hacerlo equivale básicamente a comprometerse a una actualización obligatoria cada seis meses.

Niveles de soporte ampliado

Más allá del LTS estándar, los proveedores añaden fases de soporte ampliado de pago. Oracle ofrece a las versiones LTS cinco años de «Premier Support», seguidos de tres años de «Extended Support» y, posteriormente, «Sustaining Support» de duración indefinida, que no incluye correcciones de seguridad. Red Hat ofrece una estructura similar, con una fase ELS-1 independiente para OpenJDK 11 como complemento de pago. Las ofertas de terceros, como el soporte de ciclo de vida ilimitado (Endless Lifecycle Support) de TuxCare para OpenJDK, van un paso más allá y ofrecen parches CVE continuos durante el tiempo que sea necesario, independientemente de la versión del proveedor que se haya implementado originalmente.

Consejo de experto: Tu periodo de soporte «LTS» es el que indique el proveedor cuya versión hayas descargado, no el que diga Oracle. Las versiones de OpenJDK de Microsoft, Amazon Corretto, Azul Zulu y Eclipse Temurin tienen fechas de finalización diferentes para la misma versión de Java. Consulta la página de ciclo de vida publicada por tu proveedor antes de dar por hecho que te quedan años de soporte.

Fin de la vida útil de OpenJDK 11: las fechas que realmente importan

Java 11 se lanzó en septiembre de 2018 como la segunda versión LTS tras Java 8. El calendario de soporte varía considerablemente en función de la versión que se esté utilizando y, tal y como muestra la tabla siguiente, algunos proveedores han ampliado sus plazos mucho más allá de lo que la mayoría de los equipos esperaban.

La situación es más variada de lo que la mayoría de los equipos supone. Si utilizas la versión de Red Hat sin una suscripción a ELS-1, los parches gratuitos finalizaron el 31 de octubre de 2024. Para los equipos que gestionan pilas de software más amplias en esta plataforma, estar al tanto del calendario de fin de vida útil de RHEL 8 es igualmente fundamental para la planificación operativa. El soporte Premier de Oracle finalizó incluso antes, en septiembre de 2023. Pero si utilizas Corretto, Temurin o Azul Zulu, es posible que aún te encuentres dentro del periodo de soporte activo de tu proveedor. Tu exposición real depende de la versión que estés ejecutando y de lo actualizado que esté tu nivel de parches, no solo del número de versión.

Atención: «Estamos en una versión con soporte» suele significar «descargamos la última compilación hace seis meses y no la hemos actualizado desde entonces». Los proveedores de OpenJDK lanzan actualizaciones de parches críticos cada trimestre; si el nivel de parches de tu compilación tiene más de 90 días, tienes vulnerabilidades CVE sin parchear, aunque tu versión técnicamente siga estando bajo soporte.

¿Y qué hay de OpenJDK 8?

Con Java 8 ocurre algo similar, aunque su ciclo de vida se prolongó más de lo que la mayoría esperaba. Las actualizaciones públicas gratuitas de Oracle para Java 8 finalizaron en enero de 2019 para los usuarios comerciales. Sin embargo, los proveedores han seguido manteniendo sus propias versiones mucho más allá de esa fecha.

El soporte de Red Hat para OpenJDK 8 se prolongará, como mínimo, hasta 2026 para los suscriptores de RHEL, mientras que Azul, Amazon Corretto y Eclipse Temurin han seguido ofreciendo versiones con distintos niveles de mantenimiento activo. A principios de 2026, Java 8 seguía representando una parte significativa de las cargas de trabajo en producción; según algunas encuestas, su cuota era más o menos comparable a la de Java 11.

La diferencia entre Java 8 y Java 11 es que Java 8 lleva más tiempo en fase de «extensión», por lo que las organizaciones que aún lo utilizan suelen haber tomado esa decisión de forma más deliberada. Los equipos que trabajan con Java 11 suelen encontrarse en las primeras fases de ese debate, a menudo porque la fecha de fin de vida útil les ha pillado por sorpresa.

Si gestionas cargas de trabajo tanto de Java 8 como de Java 11, las consideraciones son similares. El volumen de CVE que se acumula a lo largo de una versión LTS de larga duración da que pensar: el historial de CVE de Java 8 es un punto de referencia útil para lo que le espera ahora a Java 11 sin parches.

Java 11 y 8 siguen por todas partes

Según los datos de New Relic —obtenidos a partir de cientos de miles de aplicaciones en producción—, Java 11 y Java 8 suman en conjunto aproximadamente el 62 % de las cargas de trabajo en producción, con un 33 % para Java 11 y un 28,8 % para Java 8.

Hay razones de peso para ello, no solo inercia organizativa. Java 11 y 8 son versiones estables y bien conocidas que sustentan aplicaciones web, servicios de backend, plataformas de middleware y herramientas internas en prácticamente todos los sectores. Muchas de ellas dependen de marcos de trabajo con sus propias limitaciones de ciclo de vida: si una plataforma de middleware solo está certificada para Java 11, actualizar el entorno de ejecución no es una decisión que el equipo de operaciones pueda tomar por su cuenta.

Reescribir o actualizar una aplicación no siempre es viable cuando es fundamental para el negocio, está mal documentada o la mantiene un equipo que cuenta con la mitad de personal que cuando se creó la aplicación. Eso no es un fracaso, es la realidad de cómo funciona el software empresarial.

¿Qué ocurre cuando finaliza el soporte técnico de la comunidad?

Al día siguiente del fin de vida útil (EOL), no ocurre nada dramático. Tus JVM siguen funcionando. Tus aplicaciones siguen respondiendo. Ese es precisamente el problema: el fallo es silencioso y se manifiesta más tarde como una vulnerabilidad CVE que no se puede corregir.

Esto es lo que cambia realmente:

• Dejan de publicarse parches CVE para tu versión de Java: Cualquier vulnerabilidad descubierta tras el fin de vida útil (EOL) nunca se corregirá en tu entorno de ejecución a través de los canales gratuitos; se acumula y tu exposición aumenta con cada nueva revelación.
• Los marcos de cumplimiento empiezan a generar problemas:SOC 2, PCI DSS, HIPAA y FedRAMP exigen una gestión documentada de los parches para las vulnerabilidades conocidas. Ejecutar un entorno de ejecución EOL no provoca automáticamente un fallo en la auditoría, pero defenderlo se vuelve cada vez más difícil.
• La deriva de las dependencias se acelera: Las bibliotecas y los marcos de trabajo dejan de dar soporte a las versiones antiguas de Java a medida que sus propios ecosistemas avanzan, por lo que el software que rodea a tu entorno de ejecución congelado se va degradando silenciosamente en cuanto a compatibilidad.
• Las imágenes base de contenedores dejan de actualizarse: Las imágenes openjdk:11 de Docker Hub quedaron obsoletas mucho antes de la fecha de fin de vida útil (EOL) de la comunidad. Si sigues descargándolas, estás descargando una instantánea estática que contiene vulnerabilidades conocidas.
• La responsabilidad del proveedor recae sobre usted: La mayoría de los contratos de software empresarial incluyen cláusulas sobre la ejecución de software compatible. Una vez que se utiliza un entorno de ejecución en fase de fin de vida útil, usted asume ese riesgo personalmente.

Por qué «simplemente actualizar» es más difícil de lo que parece

El consejo habitual —«actualizar a Java 17 o 21»— es la respuesta correcta en una presentación, pero la respuesta equivocada para muchos proyectos de código real. A continuación explicamos por qué los equipos siguen utilizando OpenJDK 11 incluso sabiendo que probablemente no deberían hacerlo.

Dependencia de bibliotecas y marcos

Es sorprendente la cantidad de aplicaciones Java en producción que dependen de bibliotecas que no se han recompilado ni probado con las últimas versiones del JDK desde hace años. Al pasar de Java 11 a 17, empiezan a surgir problemas con:

• Se han eliminado las API de las que dependían de forma implícita las bibliotecas más antiguas
• Una encapsulación más estricta (introducida en Java 9 y reforzada desde entonces) que hace que las bibliotecas antiguas de manipulación de bytecode dejen de funcionar
• Incompatibilidades con herramientas como versiones antiguas de Lombok, Mockito o Byte Buddy
• JAXB, JAX-WS y otras API de Java EE que se han eliminado por completo del JDK

Imagina un equipo de ingeniería de 20 personas en plena migración: han actualizado el código de la aplicación, las herramientas de compilación y el proceso de integración continua. Entonces, su biblioteca interna de SSO —cuya última actualización la realizó un ingeniero que se marchó hace tres años— da un IllegalAccessError en la primera prueba de integración. Eso supone una semana de depuración antes de que decidan crear una bifurcación de la biblioteca, y eso es solo una dependencia.

Paquetes de aplicaciones certificados

Los proveedores de software empresarial certifican sus productos para versiones específicas de Java. Los sistemas ERP, las plataformas bancarias, las herramientas de suscripción de seguros y el software sanitario suelen incluir una matriz de compatibilidad en la que se indica «Java 8 y 11», y nada más. Actualizar el JDK subyacente anula el contrato de asistencia técnica. En ese caso, la actualización del entorno de ejecución no se ve obstaculizada por la complejidad del código, sino por una cláusula contractual.

Coste de la migración y tolerancia al riesgo

Las migraciones provocan fallos: eso es lo que los equipos han aprendido de cada cambio de versión LTS anterior. Una migración realista de Java 11 a 17 para un código base de cierta complejidad implica auditar todas las dependencias directas y transitivas (a menudo más de 200 bibliotecas), actualizar las herramientas de compilación y los procesos de integración continua, volver a ejecutar conjuntos completos de pruebas de regresión y pruebas de carga, coordinar entre servicios y refactorizar en torno a las API eliminadas. Para un equipo que gestiona 10 servicios, esto supone una cuarta parte del tiempo de ingeniería. Para un equipo que gestiona 200 servicios, es un programa de un año de duración.

La realidad: A los proveedores les encanta publicar guías de «migración fácil» que muestran una actualización de Java 8 a 17 en un vídeo de 30 minutos. Esas demostraciones utilizan aplicaciones Spring Boot limpias con cinco dependencias. Tu código de producción acumula años de complejidad, varias bifurcaciones de bibliotecas internas abandonadas y, probablemente, al menos un archivo JAR cuyo origen nadie conoce. Planifica teniendo eso en cuenta, no la demostración.

Qué hacer cuando OpenJDK 11 llegue al final de su ciclo de vida

Hay tres vías realistas para seguir adelante, y la más adecuada depende del margen de maniobra del que se disponga realmente en materia de migración.

Soporte de ciclo de vida extendido

Si no puedes realizar la migración a corto plazo, pero tampoco puedes permitirte dejar sin parchear las vulnerabilidades (CVE), el soporte ampliado es la solución más adecuada. Los principales proveedores, como Oracle y Red Hat, ofrecen planes de soporte ampliado de pago con condiciones definidas, mientras que los proveedores independientes cubren las necesidades de aquellas organizaciones que requieren una solución más flexible.

El servicio Endless Lifecycle Support (ELS) de TuxCare para OpenJDK abarca las versiones 6, 7, 8, 11 y 17, incluidas aquellas que ya han superado su fecha de fin de vida útil (EOL) según la comunidad. Está diseñado específicamente para equipos que necesitan parches de seguridad continuos sin verse obligados a cumplir un calendario de actualizaciones que, en la práctica, no pueden respetar:

• Parches CVE adaptados para versiones de OpenJDK que ya han superado su fecha de fin de vida útil (EOL)
• Independiente del proveedor: funciona independientemente de si inicialmente se implementó la versión de OpenJDK de Red Hat, Adoptium, Corretto o una instalación personalizada
• No es necesario modificar el código de la aplicación
• La cobertura se mantiene durante todo el tiempo que la necesites, no se limita a un periodo fijo de dos o tres años
• Abarca las variantes de Enterprise Linux y las distribuciones basadas en Debian, entre las que se incluyen RHEL, CentOS, AlmaLinux, Rocky Linux, Oracle Linux, Debian y Ubuntu.

El ELS de TuxCare para OpenJDK es una solución a nivel de tiempo de ejecución: aplica parches específicamente al entorno de ejecución de Java. Si además utilizas una distribución de Linux al final de su ciclo de vida (por ejemplo, CentOS 7), TuxCare ofrece un ELS independiente para sistemas operativos que cubre el conjunto completo de paquetes del sistema operativo, incluido OpenJDK cuando forma parte de dicho conjunto. Se trata de productos independientes. ELS para OpenJDK le ofrece cobertura de tiempo de ejecución independientemente de su sistema operativo; ELS para el sistema operativo cubre toda la distribución. Dependiendo de su situación, es posible que necesite uno, el otro o ambos.

Si tu preocupación se limita exclusivamente al entorno de ejecución de Java —incluso si lo ejecutas en un sistema operativo actual y compatible—, TuxCare ELS para OpenJDK se encarga de ello sin necesidad de una suscripción a nivel del sistema operativo.

Actualizar a Java 17 o Java 21

Si dispones de los recursos técnicos necesarios y tu entorno lo permite, migrar a una versión LTS actual es la mejor solución a largo plazo. Según New Relic, la adopción de Java 17 alcanzó el 35 % de las aplicaciones en producción en 2024, y la tasa de adopción de Java 21 en sus primeros seis meses superó a la de Java 17 casi tres veces.

Java 17 supone un importante paso adelante, aunque cuenta con su propio calendario de soporte que hay que tener en cuenta a la hora de planificar. Infórmate sobre el fin de vida útil (EOL) de OpenJDK 17 antes de decidirlo como tu objetivo a largo plazo.

Algunos puntos de partida prácticos:

• Ejecutar jdeps --jdk-internals comparar con los archivos JAR de tu aplicación para detectar a tiempo el uso de API internas que se han eliminado
• Comprueba que todas las dependencias de Maven/Gradle sean de la última versión compatible con la versión de Java a la que te diriges
• Organiza la migración a través de entornos de desarrollo, pruebas y una implementación canaria antes del despliegue generalizado
• Reserva tiempo específicamente para las sorpresas del tipo «hemos encontrado otra biblioteca»: no son una posibilidad remota

Java 21 es la mejor opción si puedes optar por ella. Cuenta con uno de los periodos de soporte más largos entre todos los proveedores e incluye subprocesos virtuales, lo que puede reducir considerablemente la sobrecarga del grupo de subprocesos en cargas de trabajo de alta concurrencia.

Seguir utilizando productos en fase de fin de vida útil y aceptar el riesgo

Esto es lo que muchos equipos están haciendo discretamente. Si eliges este camino, hazlo a conciencia:

• Documenta la decisión de manera oficial y obtén la aprobación de los responsables de seguridad y cumplimiento normativo
• Implementar controles compensatorios (WAF, autoprotección de aplicaciones en tiempo de ejecución, políticas de red más estrictas)
• Revisa semanalmente los boletines de CVE para Java 11 y Java 8 y evalúa cada vulnerabilidad en función de tu exposición real
• Fija una fecha límite firme para la migración o la adopción del soporte ampliado: si te limitas a decir «ya lo haremos en algún momento», acabarás seguindo con Java 11 en 2028

Esta es la opción más arriesgada y no es sostenible a largo plazo. Pero si la alternativa realista es lanzar una migración a medio probar en dos semanas, una pausa documentada y controlada es a veces la opción más defendible. La diferencia fundamental radica en la intencionalidad.

Desde la primera línea: Los equipos que gestionan mejor las transiciones de fin de vida útil (EOL) son aquellos que empezaron a planificarlas 12 meses antes de la fecha. Si estás leyendo esto en 2026 y sigues utilizando OpenJDK 11 sin un plan, ya no te queda margen de maniobra. Elige una de estas tres opciones este trimestre.

Qué hacer ahora que OpenJDK 11 ha llegado al final de su ciclo de vida

El soporte de la comunidad de OpenJDK 11 finalizó a finales de 2024, y los plazos de soporte de varios proveedores expirarán en los próximos años. A tus JVM no les importan esas fechas, pero a tus auditores, a tu responsable de seguridad de la información (CISO) y a tu equipo de respuesta a incidentes les importarán cada vez más.

Si puede realizar la migración, opte por Java 21 en lugar de Java 17: el periodo de soporte es más largo y los subprocesos virtuales suponen una mejora significativa para las cargas de trabajo de alta concurrencia. Si la migración no es viable en este momento, pero necesita parches de seguridad continuos, TuxCare ELS para OpenJDK cubre Java 8, 11 y otras versiones que han superado su fin de vida útil en múltiples entornos empresariales basados en Linux y Debian; vale la pena evaluarlo antes de su próxima revisión de cumplimiento.

Elijas el camino que elijas, hazlo a conciencia. El peor resultado es el que se da por defecto: quedarse con Java 11 al final de su ciclo de vida porque nadie tomó la decisión consciente de hacer otra cosa.

Resumen

Nombre del artículo

Fin de la vida útil de OpenJDK 11: fechas, riesgos y opciones disponibles (Guía para 2026)

Descripción

Explicación del fin del ciclo de vida de OpenJDK 11: fechas clave, riesgos de seguridad y opciones para actualizar o ampliar el soporte en 2026.

Autor

Rohan Timalsina

Nombre del editor

TuxCare

Logotipo de la editorial