Fin de la vida útil de OpenJDK 17: fechas clave, opciones disponibles y asistencia técnica

Principales conclusiones

• OpenJDK 17 no tiene una fecha concreta de fin de vida útil, y el soporte técnico de los proveedores se prolongará desde septiembre de 2026 hasta, como mínimo, octubre de 2029.
• Una vez que finaliza el soporte técnico, dejan de publicarse parches para las vulnerabilidades CVE y resulta más difícil superar las auditorías de cumplimiento y renovar los seguros.
• Los equipos que aún no estén preparados para la migración pueden seguir recibiendo parches para vulnerabilidades CVE a través del soporte ampliado de terceros sin necesidad de modificar su entorno de ejecución ni su código.

Si tus cargas de trabajo de producción siguen ejecutándose en OpenJDK 17, no eres el único. Java 17 fue la opción LTS «segura» por una razón: es estable, cuenta con un buen soporte técnico y es ampliamente compatible. El problema es que el concepto de «soporte técnico» ahora significa algo diferente dependiendo de la distribución que utilices, y las fechas no coinciden.

Este artículo explica qué significa realmente en la práctica el fin de vida útil (EOL) de OpenJDK 17, las fechas concretas para las versiones más habituales, por qué la migración es más complicada de lo que parece según la documentación y cuáles son tus opciones reales cuando la fecha límite se acerca antes de que el código esté listo.

Resumen del ciclo de vida y el soporte técnico de OpenJDK

OpenJDK es la implementación de referencia de código abierto de Java SE, gestionada por Oracle. Sin embargo, no es lo mismo que «Oracle JDK», y esa distinción es precisamente lo que hace que la planificación del fin de vida útil resulte confusa.

La comunidad OpenJDK (upstream) ofrece soporte para una versión principal durante aproximadamente seis meses, hasta que se lanza la siguiente versión con nuevas funcionalidades. El soporte a largo plazo (LTS) es una cuestión de la comunidad downstream, de la que se encargan los proveedores que empaquetan y aplican parches a sus propias compilaciones. Desde que Java pasó a un ciclo de lanzamiento de seis meses, solo algunas versiones reciben la designación LTS. Java 17 es una de ellas. Java 21 y Java 25 son versiones LTS más recientes.

Esta es la situación actual de las versiones LTS:

La adopción sigue estando muy por detrás de estas fechas. El Informe sobre la productividad de los desarrolladores de Java de 2025, elaborado por JRebel, reveló que el 61 % de los encuestados sigue utilizando Java 17. En el conjunto de la muestra, el 72 % afirmó utilizar distribuciones de Oracle que ya no cuentan con soporte público gratuito, incluido un 35 % que utiliza Java 8 y un 32 % que utiliza Java 11. Es muy probable que tu equipo esté gestionando al menos una versión al final de su ciclo de vida (EOL) junto con aquella a la que tengáis previsto migrar.

Fechas clave de OpenJDK 17

Lo más importante que hay que tener en cuenta es que no existe una fecha única de fin de vida útil (EOL) para OpenJDK 17. Cada distribución sigue su propio calendario.

Las dos fechas que la mayoría de los equipos deberían tener en cuenta en estos momentos son la fecha límite del servicio Premier Support de Oracle, en septiembre de 2026, y la de Red Hat, en diciembre de 2027. Si utilizas Oracle JDK 17 sin una suscripción universal, las actualizaciones de seguridad gratuitas dejaron de estar disponibles en septiembre de 2024. Para seguir recibiendo actualizaciones, es necesario disponer de una suscripción universal de pago a Oracle Java SE.

Para obtener un desglose completo de las diferencias entre las versiones de Oracle y OpenJDK en cuanto a condiciones de licencia y soporte técnico, consulta nuestra guía «OpenJDK frente a Oracle JDK ».

Java 17 fue la versión LTS lanzada cuando Oracle anunció el cambio a un ciclo LTS de dos años; a partir de Java 21, el intervalo entre versiones LTS se redujo de tres a dos años. Este ciclo más corto implica que la presión para actualizar afecta ahora a las empresas cada dos años en lugar de cada tres, pero los plazos de migración de la mayoría de los equipos aún no se han adaptado a este cambio.

¿Qué ocurre realmente cuando OpenJDK 17 llega al final de su ciclo de vida?

Tu JVM sigue funcionando. Esa es la parte que lleva a los equipos a ignorar las fechas de fin de vida útil (EOL): nada falla desde el primer día. La aplicación que ayer funcionaba correctamente tiene exactamente el mismo aspecto mañana. Lo que cambia es lo que ocurre en las fases previas. O, más concretamente, lo que deja de ocurrir.

Hay tres factores que empiezan a acumular riesgo de forma latente tras el fin de la vida útil.

1. Fin de los parches de seguridad

Esta es la cuestión clave. Tras el fin de la vida útil (EOL), el responsable del mantenimiento deja de incorporar retroactivamente las correcciones de CVE a tu versión. Las nuevas vulnerabilidades que se detecten en el funcionamiento interno de la JVM, en la biblioteca estándar, en las implementaciones de TLS o en las rutas de deserialización… ninguna de ellas se corregirá en tu compilación. Se corregirán en Java 21 y 25. Tu versión simplemente se queda tal y como está.

La JVM no es un objetivo menor. Java se ha visto implicado en algunas de las clases de vulnerabilidades más explotadas durante la última década, y siguen apareciendo CVE en cada ciclo trimestral de actualizaciones críticas de parches. Una vez que tu versión deja de figurar en esa lista, vas acumulando todos los problemas sin parchear que surjan entre el fin de la vida útil (EOL) y el momento en que finalmente completes la migración.

2. El cumplimiento normativo se complica

La mayoría de los marcos de cumplimiento —PCI DSS, HIPAA, SOC 2, FedRAMP, ISO 27001— incluyen requisitos explícitos o implícitos sobre la necesidad de utilizar software compatible con los parches más recientes. Los auditores son cada vez más exigentes al respecto, y «teníamos previsto actualizarlo» no es una respuesta satisfactoria en un informe de conclusiones.

Si utilizas una versión de Java que ha llegado al final de su ciclo de vida (EOL), te encontrarás en la siguiente situación:

• Errores en los análisis automáticos de vulnerabilidades: Nessus, Qualys, Wiz y otras herramientas similares señalan de forma predeterminada los entornos de ejecución que han llegado al final de su vida útil (EOL).
• Dedicar tiempo adicional a documentar y justificar las excepciones en cada ciclo de auditoría
• Un factor que complica las renovaciones de los seguros cibernéticos: varias aseguradoras importantes preguntan ahora directamente si se utiliza software al final de su ciclo de vida (EOL) en el entorno de producción
• Afrontar el riesgo de tener que revelar una filtración porque «sabíamos que no tenía fundamento» es algo muy difícil de explicar tras un incidente.

Análisis de la realidad: El informe DBIR de Verizon de 2025 reveló que el aprovechamiento de vulnerabilidades como vector de acceso inicial creció un 34 % respecto al año anterior, y ahora representa el 20 % de las filtraciones. Los entornos de ejecución sin parches son precisamente donde se produce esto.

3. El deterioro de las dependencias es un problema que avanza lentamente

Esto pilla desprevenidos a los equipos que creen que ya lo tienen todo previsto. Aunque tu entorno de ejecución de Java se quede en la versión 17, el resto de tu pila no se queda estancado con él.

Los marcos de trabajo dejan de ser compatibles con las versiones antiguas de JDK. Spring Boot lanza una nueva versión principal cada año y eleva de forma habitual su nivel de referencia. Los responsables del mantenimiento de las bibliotecas dejan de realizar pruebas con JVM que han llegado al final de su vida útil (EOL). Las imágenes base de los contenedores se recompilan con JDK más recientes. Llega un momento en el que te encuentras con una actualización de dependencias en la que una biblioteca transitiva requiere una característica que solo existe en Java 21 o superior, y la actualización que llevas dos años posponiendo de repente tiene que realizarse en este sprint, en el peor momento posible.

Por qué actualizar no siempre es sencillo

El salto de Java 17 a la versión 21 o 25 es, sin duda, más fluido que la mayoría de las migraciones a versiones principales anteriores. Pero eso no significa que sea barato. Y aquí es donde los equipos se atascan de verdad.

No todas tus dependencias están listas

Actualizar la versión de Java no consiste simplemente en cambiar la JVM. Afecta a todas las bibliotecas, marcos de trabajo y artefactos internos que dependen de un nivel específico de bytecode o que se basan en componentes internos que han cambiado de una versión a otra.

Entre las averías más habituales en el tramo 17 → 21 se incluyen:

• Las bibliotecas que hacen un uso intensivo de la reflexión se enfrentan a normas de encapsulación más estrictas
• Las herramientas más antiguas de manipulación de bytecode —ASM, algunas versiones de Byte Buddy, versiones antiguas de Hibernate— necesitan actualizaciones importantes.
• Codificar utilizando sun.misc.Unsafe que generen advertencias de obsolescencia o que las API hayan sido eliminadas por completo
• Herramientas de compilación (Maven Surefire, Gradle, JaCoCo) que requieren actualizaciones de versión sincronizadas
• Imágenes de contenedores y ejecutores de CI que requieren actualizaciones en paralelo

Un equipo que trabaje con un monolito de cuatro años de antigüedad suele descubrir la mayor parte de esto solo después de que la rama de actualización llegue a CI. Hay que prever un presupuesto para ello.

Probablemente, tu cobertura de pruebas no sea tan buena como te parece

Las actualizaciones de la JVM sacan a la luz errores que las pruebas unitarias no detectan. El comportamiento de la recolección de basura varía de una versión a otra. Los ajustes predeterminados cambian. El compilador JIT toma decisiones diferentes. El manejo de la configuración regional, el de la zona horaria y el comportamiento del motor de expresiones regulares: todos estos aspectos han provocado incidentes reales en producción en actualizaciones anteriores.

Si tu conjunto de pruebas no simula bases de datos reales, operaciones de E/S reales y perfiles de carga realistas, la actualización superará las pruebas de integración (CI) pero fallará en producción. Esta es la parte del plan de migración que se suele omitir sin que nadie se dé cuenta, y es la causa de la mayoría de los análisis a posteriori del tipo «ya hemos actualizado, ¿por qué no funciona nada?».

El calendario no coincide con el código fuente

Aunque la migración técnica sea factible, la realidad organizativa a menudo no lo es. La capacidad de ingeniería se asigna trimestre a trimestre. La actualización compite con el desarrollo de nuevas funcionalidades, los retrasos en materia de seguridad y cualquier incidente que acapare la atención del equipo esa semana. Una migración que, sobre el papel, se estima en tres meses, acaba durando nueve meses en la práctica porque nadie puede dedicarle tiempo de forma ininterrumpida.

Desde la trinchera: Un patrón habitual: un equipo planifica la actualización de Java 17 a 21 para el primer trimestre, se encuentra con un conflicto de versiones principales de Spring Boot, la aplaza al segundo trimestre, se ve envuelto en un ciclo de preparación para la auditoría SOC 2 y todo se retrasa hasta el cuarto trimestre. Para entonces, Java 25 ya está disponible y el objetivo vuelve a cambiar. Los equipos que realmente cumplen sus plazos consideran las fechas de fin de vida útil (EOL) como hitos fijos del proyecto con responsables designados, y no como tareas pendientes a las que se dedicarán en algún momento.

Tus opciones tras el fin de la vida útil (EOL) de OpenJDK 17

No hay una única respuesta correcta. La mejor opción depende de tu capacidad técnica, de lo cerrada que sea tu pila tecnológica y de lo estrictos que sean tus requisitos de cumplimiento normativo. Estas son las opciones realistas.

Opción 1: Soporte ampliado de terceros para OpenJDK 17

Si la actualización no es viable dentro de tu plazo actual, el soporte de ciclo de vida ampliado de terceros es la forma más sencilla de seguir recibiendo parches CVE sin tener que modificar tu entorno de ejecución ni refactorizar tu código. Este enfoque funciona especialmente bien para equipos que utilizan OpenJDK 17 en distribuciones mixtas de Linux —RHEL, AlmaLinux, Rocky, Ubuntu, Debian— en las que los ciclos de vida del soporte del sistema operativo y del JDK no coinciden perfectamente.

El servicio de soporte de ciclo de vida ilimitado de TuxCare para OpenJDK proporciona parches de seguridad continuos para las versiones 17, 11, 8 y 7 de OpenJDK, lo que abarca la mayoría de las principales distribuciones de Linux para empresas. El enfoque es sencillo: conservas tus compilaciones actuales, sigues recibiendo parches a medida que surgen nuevas vulnerabilidades (CVE) y ganas tiempo para planificar una migración bien meditada, en lugar de una apresurada. Está diseñado específicamente para equipos con restricciones normativas que no pueden permitirse ejecutar entornos de ejecución sin parches, pero que tampoco pueden dejarlo todo de lado para llevar a cabo una actualización de versión importante este trimestre.

Opción 2: Actualizar a Java 21 o Java 25

La solución adecuada a largo plazo para la mayoría de los equipos. Si dispones de los recursos técnicos necesarios, actualizar a una versión LTS actual te proporcionará años de soporte público gratuito, mejoras significativas en el rendimiento y compatibilidad continua con el ecosistema a medida que este evoluciona. Según la hoja de ruta de soporte de Oracle, Java 21 cuenta con soporte Premier hasta septiembre de 2028 y Java 25 hasta septiembre de 2030; no obstante, si utilizas Corretto, Temurin u otra versión, consulta el calendario específico de tu proveedor.

Esta es la decisión correcta cuando:

• Tu código es lo suficientemente pequeño o está lo suficientemente bien probado como para migrarlo en un trimestre
• Tu cobertura de CI detectará realmente los cambios de comportamiento, no solo los errores de compilación.
• Tus principales dependencias ya son compatibles con Java 21 y versiones posteriores.
• Puedes organizar un sprint de ingeniería bien definido sin que te veas tirado en tres direcciones diferentes

Opción 3: Cambiar a otra distribución de OpenJDK

Si utilizas Oracle JDK 17 y el cambio en la política de licencias de septiembre de 2024 te ha pillado por sorpresa, no es necesario que migres a Java 21 ahora mismo para evitar el problema de las licencias. Puedes cambiar a Eclipse Temurin, Amazon Corretto o la versión de OpenJDK de Microsoft sin modificar tu código Java: todas ellas cuentan con la certificación TCK y su comportamiento es idéntico para la gran mayoría de las cargas de trabajo.

La migración desde Oracle JDK lleva ya unos años en marcha: los datos de New Relic muestran que la cuota de mercado de Oracle en el sector del JDK cayó del 75 % en 2020 al 21 % en 2024, mientras que Eclipse Adoptium creció un 50 % interanual. La mayoría de los equipos que se cambiaron no tuvieron que modificar ni una sola línea de código Java para hacerlo.

Algunas cosas que debes comprobar antes de cambiar:

• Confirma la fecha de fin de vida útil (EOL) de la nueva distribución de Java 17; estas fechas varían entre uno y tres años.
• Comprueba si hay opciones o extensiones de la JVM específicas del proveedor (es poco habitual, pero merece la pena revisarlo).
• Actualiza el aprovisionamiento, las imágenes de contenedores y la integración continua (CI) para que se obtengan de la nueva fuente
• Documenta el cambio para los registros de cumplimiento normativo

Atención: Cambiar de distribución es una medida táctica, no una solución a largo plazo. Corretto 17 y la versión de Microsoft amplían el soporte más allá del plazo de Red Hat en algunos casos, pero todos ellos llegan a su fin tarde o temprano. Aprovecha el cambio para ganar entre 12 y 24 meses de margen, pero no lo utilices como excusa para dejar de planificar la migración propiamente dicha.

Opción 4: Aceptar el riesgo (de forma deliberada)

Hay equipos que realmente toman esta decisión y, en determinados contextos, es justificable. Herramientas internas, entornos aislados, cargas de trabajo desechables… No todo justifica el coste técnico que supone mantener un entorno de ejecución actualizado.

Toma la decisión de forma consciente, documéntala y segmenta el riesgo para que no haya ninguna JVM sin parches en un punto final expuesto al público. Combina esto con un enfoque automatizado de gestión de parches para el resto de tu pila, de modo que el componente sin soporte no se convierta, por defecto, en el eslabón más débil. Y, por otra parte, comprende la diferencia entre la gestión de parches y la gestión de vulnerabilidades: no son la misma disciplina, y confundirlas es precisamente lo que hace que, en primer lugar, se pasen por alto los componentes sin soporte.

Protección de OpenJDK tras el fin de su ciclo de vida con TuxCare

La incómoda verdad sobre el fin de vida útil (EOL) de Java es que el hecho de que «el entorno de ejecución siga funcionando» es precisamente lo que hace que sea fácil dejar de darle prioridad. Dejan de publicarse parches, las dependencias se deterioran, se acumulan los resultados de las auditorías… y, de repente, un día aparece un CVE con un exploit que funciona y tu versión no figura en la lista de parches.

Si tu equipo utiliza OpenJDK 17 y el calendario de migración previsto sobre el papel no se ajusta a la realidad, no es una situación inusual. La actualización es la solución adecuada a largo plazo. Pero si aún te faltan uno o dos trimestres para estar listo para llevarla a cabo correctamente, seguir utilizando la versión sin parches mientras tanto supone un riesgo real.

El servicio de soporte de ciclo de vida ilimitado de TuxCare para OpenJDK está diseñado precisamente para ese periodo: mismas compilaciones, mismos flujos de trabajo y parches CVE que no caducan cuando el calendario de soporte del proveedor original indica que deberían hacerlo. Abarca las versiones 7, 8, 11 y 17 de OpenJDK en sistemas Enterprise Linux y basados en Debian, durante todo el tiempo que su organización necesite. Consulta los precios o ponte en contacto con los expertos de TuxCare para evaluar qué cobertura se adapta mejor a tu entorno.

Resumen

Nombre del artículo

Fin de la vida útil de OpenJDK 17: fechas clave, opciones disponibles y asistencia técnica

Descripción

Fechas de fin de vida útil de OpenJDK 17, plazos de soporte, diferencias entre proveedores y opciones de actualización. Descubre qué significa «EOL» y cómo prepararte para Java 17.

Autor

Rohan Timalsina

Nombre del editor

TuxCare

Logotipo de la editorial