Fin de la vida útil de Eclipse Jetty: versiones, proceso de actualización y opciones

Principales conclusiones

• Las versiones 8, 9, 10 y 11 de Jetty han llegado al final de su ciclo de vida. El 1 de enero de 2026, Webtide y el proyecto Jetty dejaron de publicar versiones de las líneas 9, 10 y 11 en Maven Central, por lo que ya no se publican correcciones para nuevas vulnerabilidades CVE a través de los canales públicos.
• Solo las versiones 12.0 y 12.1 de Jetty siguen contando con soporte por parte de la comunidad. Jetty 12.1 es la versión actual; Webtide ha anunciado que las actualizaciones de la versión 12.0 dejarán de realizarse en algún momento de 2026, aunque aún no ha confirmado una fecha concreta.
• Pasarse a Jetty 12 es algo más que un simple cambio de versión. Requiere el JDK 17 y, dependiendo del entorno EE al que te dirijas, una migración de javax a jakarta y, en el caso de las aplicaciones Spring Boot integradas, pasar a Spring Boot 3.2 o una versión posterior.
• Si aún no puedes realizar la migración, las opciones realistas son el soporte ampliado ofrecido por el proveedor, los backports de mantenimiento propio o sustituir Jetty. El soporte ampliado suele ser la solución de transición que requiere menos esfuerzo; el mantenimiento propio es la opción que los equipos suelen subestimar.

El trimestre pasado actualizaste todo. Entonces, un análisis de dependencias detectó que «jetty-server 9.4.x» estaba oculto a tres niveles de profundidad en un servicio que nadie ha tocado desde 2021, y la versión corregida que necesitas no está en Maven Central. Así es la situación de Eclipse Jetty tras el fin de su ciclo de vida (EOL) en 2026: Jetty 9, 10 y 11 han llegado al final de su ciclo de vida y, desde el 1 de enero de 2026, el proyecto ya no publica versiones de esas líneas de forma pública.

Esta guía explica qué versiones han llegado al final de su ciclo de vida, cómo saber si estás utilizando una de ellas, cuáles son los riesgos reales y cuál es la forma más sencilla de dejar de usarla.

¿Ha llegado Eclipse Jetty al final de su ciclo de vida?

Sí, y el calendario tiene más variables de las que la mayoría de los equipos habían percibido. Jetty 10 y 11 alcanzaron el fin del soporte comunitario el 1 de enero de 2024 y se declaró el fin de su vida útil a partir de enero de 2025. Jetty 9 dejó de contar con soporte comunitario el 1 de junio de 2022 y su fin de vida útil estaba previsto para enero de 2025, aunque se siguieron lanzando versiones de seguridad patrocinadas por los clientes hasta que se publicó la versión 9.4.58.v20250814 en agosto de 2025.

La fecha que cambia tu cálculo de riesgo es más reciente. Desde el 1 de enero de 2026, Webtide y el proyecto Jetty ya no publican las versiones 9, 10 ni 11 de Jetty en Maven Central ni en ningún otro repositorio público. Por lo tanto, cuando hoy se publica un CVE relacionado con una versión anterior a la 12, suele existir una versión corregida. Simplemente, no se encuentra en ningún lugar al que tu compilación pueda acceder.

Jetty 12.0 y 12.1 son las únicas versiones que cuentan con soporte por parte de la comunidad, y la 12.0 está en fase de aviso.

Nota: Jetty 9 es la versión que más probablemente se esté ejecutando en tu entorno sin que nadie haya decidido instalarla. Las versiones de Apache Solr, Spark, ActiveMQ y Hadoop se han distribuido con Jetty integrado, y el complemento de Maven para Jetty lo incluye en las compilaciones, por lo que suele incorporarse a la compilación como una dependencia empaquetada o transitiva, más que como una elección deliberada.

Versiones y fechas clave de Eclipse Jetty

La correspondencia entre versiones y estados es lo que la mayoría de los lectores realmente necesitan, así que aquí la presentamos desde el principio, actualizada a julio de 2026 y extraída de los anuncios oficiales y listas de lanzamientos de Eclipse Jetty.

Una salvedad respecto a esa segunda columna: existen números de versión fijos más altos para las líneas que han llegado al final de su vida útil (EOL), entre ellos el 9.4.60 y posteriores, el 10.0.28 y posteriores, y el 11.0.28 y posteriores. Esas compilaciones no se publican en Maven Central, por lo que la tabla termina donde lo hace.

Cómo comprobar si estás utilizando una versión de Eclipse Jetty que ha llegado al final de su vida útil (EOL)

Hay dos situaciones que requieren comprobaciones diferentes. La versión independiente de Jetty es fácil de encontrar. La versión integrada de Jetty es donde los equipos suelen meterse en problemas.

Si ejecutas Jetty como servidor independiente, pregúntaselo directamente:

java -jar $JETTY_HOME/start.jar –version

Esto muestra la versión exacta de la compilación; por ejemplo jetty-12.1.11. También puedes consultar el archivo VERSION.txt en el directorio principal de Jetty.

Si Jetty está integrado en una aplicación de Spring Boot, una instancia de Solr o cualquier JAR «fat», la versión queda oculta en el árbol de dependencias. Para Maven:

mvn dependency:tree -Dincludes=’org.eclipse.jetty*’

Mantén el comodín final. Jetty 12 publica sus artefactos de entorno bajo identificadores de grupo independientes, como org.eclipse.jetty.ee10, y un filtro de coincidencia exacta de org.eclipse.jetty no los mostrará. Si prefieres no tener que lidiar con la sintaxis del filtro, utiliza mvn dependency:tree | grep -i jetty lo detecta todo.

Para Gradle:

./gradlew dependencies | grep -i jetty

Y para detectar los archivos JAR de Jetty que se encuentran en el disco dentro de otros productos:

find / -name «jetty-*.jar» 2>/dev/null

Apúntalo a la raíz de una aplicación real en lugar de / si el host tiene montajes de gran tamaño o en red, y recuerda que un JAR dentro de un «fat JAR» o de una capa contenedora no aparecerá en absoluto como un archivo independiente.

Si el resultado es 9.x, 10.x u 11.x, estás utilizando una versión de EOL de Jetty. Si es 12.0.x o 12.1.x, estás utilizando una versión con soporte técnico, aunque hay que tener en cuenta que las actualizaciones de la versión 12.0 dejarán de estar disponibles este año.

¿Qué ocurre si sigues utilizando Eclipse Jetty, que ha llegado al final de su vida útil?

El riesgo no es teórico, y no se limita únicamente a la versión que se puede ver. Se divide en tres partes: nuevas vulnerabilidades CVE cuyas correcciones nunca llegan a un repositorio público, el largo historial de errores de análisis HTTP de Jetty y la exposición a auditorías que conlleva el uso de software sin soporte técnico.

Nuevas vulnerabilidades CVE sin parche público

Una vulnerabilidad revelada hoy que afecte a Jetty 9, 10 u 11 no se publicará en Maven Central. Ese es el efecto práctico del cambio de enero de 2026, y se trata de un problema más extraño de lo que parece a primera vista, ya que normalmente sí existe una solución.

CVE-2026-2332 es el ejemplo más claro. Se trata de una vulnerabilidad de contrabando de peticiones HTTP en el analizador de codificación de transferencia por fragmentos de Jetty: Jetty finaliza el análisis de la extensión de los fragmentos en un CRLF dentro de una cadena entre comillas en lugar de tratarlo como un error, lo que permite a un atacante desincronizar Jetty de un proxy front-end. Publicado el 14 de abril de 2026, CVSS 7,4, y afectaba a las versiones 9.4.0 a 9.4.59, de la 10.0.0 a la 10.0.27, de la 11.0.0 a la 11.0.27, de la 12.0.0 a la 12.0.32 y de la 12.1.0 a la 12.1.6. Las correcciones públicas se incluyeron en las versiones 12.0.33 y 12.1.7. También existen versiones corregidas para las líneas fuera de soporte (EOL), como la 9.4.60, la 10.0.28 y la 11.0.28, pero no están disponibles en Maven Central. Los propios avisos de Jetty ahora lo indican, y enumeran los parches para versiones fuera de soporte disponibles a través de proveedores comerciales, entre ellos TuxCare.

Entonces volvió a ocurrir. CVE-2026-5795, una vulnerabilidad que permitía eludir la autenticación JASPI provocada por la persistencia del estado de ThreadLocal tras un retorno anticipado, se corrigió públicamente en las versiones 12.0.34 y 12.1.8, mientras que las versiones 9.4.61, 10.0.29 y 11.0.29 solo estaban disponibles a través de esos mismos canales de soporte ampliado. Dos avisos de alta gravedad en una sola primavera, ambos corregidos, pero sin que se pudiera acceder a ninguno de los parches desde una versión pública si se utilizaba una versión anterior a la 12.

Una aplicación de Spring Boot 2.7 que incorpora Jetty 9.4 ilustra claramente esta trampa. Sobrescribir la versión de Jetty en la compilación solo funciona si existe una versión pública a la que sobrescribirla, y en el caso de la 9.4 ya no la hay. La alternativa es un artefacto 12.x, lo que implica JDK 17, los espacios de nombres de Jakarta y una actualización importante de Spring Boot, por lo que el CVE suele quedarse simplemente en el informe. La corrección existe; lo difícil es conseguir una compilación compatible para instalarla en los servidores, y cerrar esa brecha sin una actualización forzada es precisamente para lo que sirven los parches respaldados por el proveedor.

El historial de análisis HTTP de Jetty

El punto débil recurrente de Jetty es la gestión de peticiones HTTP/1.x, y el patrón es lo suficientemente constante como para tenerlo en cuenta a la hora de planificar. CVE-2026-2332 es un error de análisis de la codificación por fragmentos, y no es ni mucho menos el primero. El CVE-2023-40167 se debía a que Jetty aceptaba un + antes del valor de Content-Length , una peculiaridad de análisis que puede permitir el «request smuggling» cuando un front-end interpreta ese encabezado de forma diferente.

La serie de 2017 presenta el mismo problema en tres errores del analizador sintáctico. CVE-2017-7656 consistía en aceptar una línea de solicitud de tipo HTTP/1 que declaraba HTTP/0.9, lo que podía contaminar la caché cuando un intermediario reenviaba la versión sin procesarla. CVE-2017-7657 consistía en un desbordamiento de entero en el análisis de la longitud de los fragmentos, por lo que un fragmento grande podía leerse como uno más pequeño y su cuerpo tratarse como una solicitud en canalización. CVE-2017-7658 se debía a un conflicto entre los indicadores de «Content-Length» y de codificación por fragmentos. En los dos últimos casos, la situación crítica se producía cuando Jetty se encontraba detrás de un intermediario que exigía autorización y transmitía la solicitud sin modificarla: la solicitud introducida de forma fraudulenta llegaba al otro lado de ese control.

De esa historia se desprenden dos conclusiones. Si Jetty se encuentra detrás de un proxy, un equilibrador de carga o una CDN, hay que considerar las vulnerabilidades CVE del analizador como de alta prioridad y no como meras cuestiones teóricas, ya que es el intermediario el que hace que sean explotables. Y si no es posible aplicar el parche de inmediato, normalizar o eliminar las extensiones de los fragmentos en el front-end constituye una medida de mitigación provisional eficaz para este tipo de errores.

Incorporación oculta y exposición al cumplimiento normativo

El problema de la dependencia transitiva complica aún más todo lo anterior. Dado que las versiones de Solr, Spark, ActiveMQ y Hadoop incluyen Jetty, y que el complemento de Jetty para Maven lo incorpora a las compilaciones, la suposición de que «no utilizamos Jetty» suele ser errónea. En un gran conjunto de servicios, es habitual encontrar más de una versión principal de Jetty en diferentes servicios, cada una con su propio nivel de exposición y su propio responsable.

También está la parte de la auditoría. La norma PCI DSS establece requisitos explícitos en materia de aplicación de parches y gestión de vulnerabilidades, FedRAMP exige que se documenten los plazos de análisis y corrección, y aunque SOC 2 es una certificación basada en los controles que tú mismo has definido, más que una obligación de aplicar parches, un auditor seguirá preguntándote cómo encaja un servidor HTTP sin soporte con los controles que has establecido. Un Jetty al final de su ciclo de vida (EOL) no supone por sí solo un fallo en la auditoría. Sin embargo, te obliga a dar explicaciones, y «la corrección del desarrollador original ya no se publica» es una respuesta poco satisfactoria si no va acompañada de un control compensatorio.

Atención: Un análisis de dependencias «verde» en los repositorios de tu aplicación no significa que estés a salvo. Jetty, que ha llegado al final de su vida útil (EOL), suele ocultarse dentro de productos de terceros que has implementado como un único artefacto, por lo que es posible que el JAR vulnerable nunca aparezca como una dependencia directa en tu propio pom.xml. Analiza los artefactos desplegados y las imágenes de contenedor, no solo los repositorios que compilas.

Proceso de actualización: Migración a Eclipse Jetty 12

El proceso de migración depende en gran medida de si tu Jetty es autónomo o está integrado. Cada uno de los pasos que se indican a continuación es un requisito previo para el siguiente, por lo que el orden es importante.

•   Primero, el JDK 17. Tanto Jetty 12.0 como 12.1 establecen Java 17 como entorno de ejecución mínimo. Si utilizas Java 8 o Java 11, este es el paso clave y, por lo general, la tarea más laboriosa.
•   A continuación, elige tu entorno EE. Jetty 12 ejecuta aplicaciones dentro de módulos específicos para cada entorno: la versión 12.0 incluye EE8, EE9 y EE10, y la 12.1 abarca desde EE8 hasta EE11. EE10 utiliza jakarta.servlet (Servlet 6.0) y EE11 utiliza Servlet 6.1, por lo que el código y las bibliotecas que importan las API javax.* de Java EE deben adaptarse a esos destinos. EE8 conserva el espacio de nombres javax.*, lo que significa que puedes implementar primero el núcleo de Jetty 12 y programar el trabajo relacionado con el espacio de nombres por separado. Vale la pena dejarlo claro para cualquiera que esté creando scripts para esto: solo se han trasladado los paquetes de Java EE. javax.crypto, javax.sql y el resto de Java SE permanecen exactamente donde están.
•   Compatibilidad entre versiones de Spring Boot para usuarios de la versión integrada. Aquí está el problema. Jetty 12 integrado necesita Spring Boot 3.2 o posterior, ya que Spring Boot 3.0 y 3.1 se distribuían con Jetty 11 y exigían rebajar la API de Servlet a la versión 5.0 para poder utilizar Jetty. A su vez, Spring Boot 3.x requiere Java 17 y el espacio de nombres de Jakarta EE 9, por lo que una solicitud de «actualización de Jetty» se convierte en una migración de Spring Boot 2 a 3 con un mínimo de la versión 3.2.

Imaginemos una aplicación SaaS basada en Spring Boot 2.7 con Jetty 9.4 integrado. La actualización de Jetty no es una simple línea en el archivo pom.xml. Se trata de un proyecto que abarca varios sprints y que afecta al JDK, a las importaciones de Java EE en todo el código fuente, a la configuración de Spring Security y a una larga lista de bibliotecas que necesitan versiones compatibles con Jakarta.

La decisión es muy clara. Si ejecutas Jetty de forma independiente y ya utilizas Java 17, la migración es más sencilla que en el caso de una instalación integrada, pero debes prever tiempo para revisar los artefactos Maven renombrados, la nueva estructura de módulos y entornos, tu configuración de jetty-base y tus descriptores de implementación. Si Jetty está integrado en una aplicación de Spring Boot 2.x, planifica primero la migración a Spring Boot 3.2 o posterior y considera la versión de Jetty como una consecuencia derivada. Y si ya estás trabajando con un migración de Spring Framework al final de su ciclo de vida , realiza ambas migraciones de forma secuencial, ya que el trabajo relacionado con Jakarta se solapa casi por completo.

Consejo de experto: Eclipse Transformer puede reescribir automáticamente las referencias a «javax.*» por «jakarta.*» en el código byte para aquellas dependencias que no se puedan recompilar a partir del código fuente. Esto elimina gran parte del trabajo repetitivo, pero los artefactos transformados deben someterse a pruebas de regresión completas y el proveedor original no les prestará soporte, por lo que conviene considerarlo como una solución provisional para una dependencia bloqueada más que como una estrategia de migración.

Tus opciones si no puedes actualizar ahora mismo

A veces, la migración no puede llevarse a cabo este trimestre. El trabajo relacionado con Spring Boot 3 es demasiado extenso, o bien un producto de un proveedor utiliza una versión antigua de Jetty sobre la que no tienes control. Aún así, tienes tres opciones viables: el soporte ampliado ofrecido por el proveedor, realizar tú mismo las adaptaciones internas o sustituir Jetty.

1. Utiliza el servicio de soporte técnico de ciclo de vida ilimitado de TuxCare para Jetty

Si aún faltan meses para la migración, el soporte ampliado ofrecido por el proveedor garantiza que Jetty, aunque haya llegado al final de su vida útil, siga recibiendo parches sin que tengas que forzar la actualización en tu calendario. El servicio «Endless Lifecycle Support» de TuxCare ofrece correcciones de seguridad para software de código abierto al final de su vida útil, y su cobertura de Jetty abarca las versiones 7, 8, 9.2, 9.4, 10 y 11, incluidas las compilaciones posteriores al fin de vida útil que abordan las vulnerabilidades CVE de 2026: 9.4.60 y posteriores, 10.0.28 y posteriores, y 11.0.28 y posteriores. Webtide se ha asociado con TuxCare para ofrecer este servicio, razón por la cual los propios avisos de Jetty ahora remiten a los usuarios de versiones fuera de ciclo de vida a proveedores de parches comerciales.

La entrega se adapta a la cadena de herramientas con la que ya cuentas. Los artefactos parcheados se publican como paquetes firmados en un registro compatible con Maven y gestionado por TuxCare, de modo que las compilaciones existentes de Maven y Gradle los utilizan simplemente apuntando a un repositorio diferente y actualizando la versión, sin necesidad de modificar el proceso de compilación.

El propio espacio ocupado por Jetty es reducido y limpio: jetty-server incluye jetty-http, jetty-io, jetty-utily slf4j-api. La clave está en dónde se ubican los CVE. jetty-http y jetty-server son precisamente donde se encuentran los errores de «request smuggling» y de análisis de URI, y jetty-http suele ser el artefacto que tu escáner señala después de haber bajado tres niveles a través de otros componentes. ELS cubre las dependencias directas y transitivas sin coste adicional, por lo que se corrigen los módulos que realmente contienen las vulnerabilidades de Jetty, y no solo el artefacto que has declarado.

Para la mayoría de los equipos, esta es la solución más pragmática. Alivia la presión inmediata en materia de seguridad y te proporciona una cobertura de parches documentada que puedes presentar en una reunión de auditoría, mientras planificas adecuadamente el trabajo con Java 17 y Spring Boot 3.2, en lugar de tener que reescribir las integraciones del servidor web integrado para cumplir con los plazos de otra persona.

2. Mantenimiento interno de Jetty

Puedes crear una bifurcación de la última versión pública de Jetty e integrar tú mismo las correcciones de seguridad. Es técnicamente posible y, en ocasiones, la mejor opción para una implementación muy personalizada que, de todos modos, nunca se iba a poder migrar sin problemas.

Además, resulta caro en el aspecto que más importa: te conviertes en el responsable del mantenimiento de tu propia bifurcación de Jetty. Alguien tiene que estar al tanto de cada nuevo aviso, leer el analizador HTTP/1.x con suficiente detenimiento como para portar correctamente una corrección de contrabando y distribuirla a través de tu proceso de compilación y lanzamiento con pruebas de regresión que lo respalden. Si te equivocas en algún matiz al corregir el analizador, distribuirás un parche que parece aplicado pero no lo está, lo cual es peor que saber que estás expuesto. Mantener eso requiere una ingeniería de seguridad dedicada y una capacidad de gestión de lanzamientos que la mayoría de los equipos de aplicaciones no tienen disponible.

3. Sustituir Jetty por una alternativa

Se está barajando la posibilidad de sustituir Jetty por otro contenedor de servlets, sobre todo si, de todos modos, ya te estabas planteando un cambio de arquitectura. Tomcat y Undertow son las opciones más similares, y para una implementación independiente con necesidades sencillas de servlets, Tomcat es una de las opciones más habituales. Netty es una propuesta diferente: se trata de un marco de trabajo de redes asíncronas de bajo nivel, más que de un contenedor de servlets, por lo que migrar a él supone una reescritura de la arquitectura, no una simple sustitución.

Sé sincero sobre la magnitud de la tarea. En el caso de una aplicación integrada, sustituir el servidor suele suponer más trabajo que actualizar Jetty: un modelo de configuración diferente, un ajuste distinto de los conectores y del grupo de subprocesos, y una nueva ronda de pruebas de carga. Una sustitución que «debería ser equivalente» tiende a poner de manifiesto diferencias de comportamiento en casos extremos bajo tráfico de producción. Y si ya estás llevando a cabo la migración a Jetty 12 de Jakarta, la mayor parte de ese trabajo se puede aprovechar, lo que hace que seguir con Jetty sea la opción menos complicada para muchos equipos.

Mantén la seguridad de Eclipse Jetty al final de su ciclo de vida con TuxCare

La cuestión de las versiones ya está zanjada. Jetty 8, 9, 10 y 11 han llegado al final de su ciclo de vida; las versiones públicas de las líneas 9, 10 y 11 dejaron de publicarse el 1 de enero de 2026, y la transición a Jetty 12 es un proyecto real, no solo una casilla que marcar. La pregunta que queda por resolver es cómo cubrir el vacío entre la situación actual y el momento en que la migración esté completada.

Si puedes pasar a Jetty 12 este trimestre, hazlo y planifica de forma realista el trabajo con JDK 17 y Spring Boot 3.2. Si no puedes, no utilices versiones sin parches, ya que existen compilaciones corregidas para las líneas en fin de vida útil (EOL), pero simplemente ya no se publican. El soporte técnico proporcionado por el proveedor mantiene corregidas las vulnerabilidades conocidas y te ofrece pruebas de un proceso de corrección activo mientras planificas. Descubre cómo TuxCare gestiona el software de código abierto al final de su ciclo de viday consulta los precios para evaluar su idoneidad en función de tu cartera.

Preguntas frecuentes

¿Qué versiones de Eclipse Jetty siguen siendo compatibles?

Solo las versiones 12.0 y 12.1 de Jetty cuentan con soporte de la comunidad. Jetty 12.1 es la versión actual y recibe correcciones de forma activa; la versión 12.0 sigue recibiendo actualizaciones, pero Webtide ha indicado que estas dejarán de proporcionarse en algún momento de 2026, aunque no ha confirmado una fecha concreta. Todas las versiones anteriores, incluidas las 8, 9, 10 y 11 de Jetty, han llegado al final de su ciclo de vida.

¿Sigue siendo seguro utilizar Eclipse Jetty 9 en entornos de producción?

No sin una fuente activa de correcciones de seguridad. Jetty 9.4 ha llegado al final de su ciclo de vida; su última versión pública fue la 9.4.58.v20250814, lanzada en agosto de 2025, y desde el 1 de enero de 2026 no se publican versiones 9.x en Maven Central. Existen versiones corregidas posteriores, pero solo a través de proveedores de soporte ampliado, por lo que utilizar la versión 9.4 de forma responsable implica contar con ese soporte, o bien aplicar controles compensatorios previos, y disponer de un plan de migración para ambos.

¿Cómo puedo saber si mi aplicación Spring Boot utiliza una versión EOL de Jetty?

Ejecuta mvn dependency:tree -Dincludes=’org.eclipse.jetty*’ o ./gradlew dependencies | grep -i jetty. Mantén el comodín, ya que Jetty 12 publica artefactos de entorno bajo identificadores de grupo como org.eclipse.jetty.ee10, que un filtro de coincidencia exacta no detectaría. Si el resultado muestra un artefacto de Jetty 9.x, 10.x u 11.x, tu aplicación se encuentra en una línea EOL, incluso si Jetty llegó como una dependencia transitiva que nunca declaraste.

¿La actualización de Jetty 10 a Jetty 12 requiere migrar de «javax» a «jakarta»?

Solo si utilizas el entorno EE10 o EE11 de Jetty 12. Jetty 10 utiliza javax.servlet, EE10 utiliza jakarta.servlet (Servlet 6.0) y EE11 utiliza Servlet 6.1. Jetty 12 también incluye los entornos EE8 y EE9, y EE8 mantiene el espacio de nombres javax.*, por lo que puedes trasladar primero el núcleo de Jetty y el JDK y tratar la migración del espacio de nombres como un proyecto independiente.

¿Qué versión del JDK requiere Eclipse Jetty 12?

Java 17. Tanto Jetty 12.0 como 12.1 establecen Java 17 como el entorno de ejecución mínimo, por lo que la actualización del JDK es el primer paso imprescindible para cualquier equipo que provenga de Jetty 9, 10 u 11 con Java 8 o Java 11.

Resumen

Nombre del artículo

Fin de la vida útil de Eclipse Jetty: versiones, proceso de actualización y opciones

Descripción

Las versiones Jetty 8, 9, 10 y 11 han llegado al final de su ciclo de vida, y las publicaciones públicas se interrumpieron en enero de 2026. Consulta las fechas de las versiones, los comandos de detección y las opciones disponibles.

Autor

Rohan Timalsina

Nombre del editor

TuxCare

Logotipo de la editorial