Fin de vie d'Eclipse Jetty : versions, procédure de mise à niveau et options

Principaux enseignements

• Les versions 8, 9, 10 et 11 de Jetty sont toutes en fin de vie. Le 1er janvier 2026, Webtide et le projet Jetty ont cessé de publier des versions des lignes 9, 10 et 11 sur Maven Central ; par conséquent, les correctifs relatifs aux nouvelles vulnérabilités CVE ne sont plus diffusés via les canaux publics.
• Seules les versions 12.0 et 12.1 de Jetty bénéficient encore d'un support communautaire. Jetty 12.1 est la version actuelle ; Webtide a indiqué que les mises à jour de la version 12.0 cesseraient courant 2026, sans toutefois s'engager sur une date précise pour l'instant.
• Le passage à Jetty 12 ne se résume pas à une simple mise à jour de version. Il nécessite le JDK 17 et, selon l'environnement EE ciblé, une migration de javax vers jakarta ainsi que, pour les applications Spring Boot embarquées, une migration vers Spring Boot 3.2 ou une version ultérieure.
• Si vous ne pouvez pas encore effectuer la migration, les options réalistes sont le support étendu assuré par l'éditeur, les backports gérés en interne ou le remplacement de Jetty. Le support étendu constitue généralement la solution de transition la moins contraignante ; la gestion en interne est quant à elle souvent sous-estimée par les équipes.

Vous avez appliqué toutes les mises à jour au cours du dernier trimestre. Puis, une analyse des dépendances a signalé la présence de jetty-server 9.4.x, enfoui à trois niveaux de profondeur dans un service que personne n’a modifié depuis 2021, et la version corrigée dont vous avez besoin n’est pas disponible sur Maven Central. Voilà où en est la fin de vie (EOL) d’Eclipse Jetty en 2026 : Jetty 9, 10 et 11 ont toutes atteint leur fin de vie, et depuis le 1er janvier 2026, le projet ne publie plus officiellement de versions pour ces branches.

Ce guide explique quelles versions sont en fin de vie, comment savoir si vous utilisez l'une d'entre elles, quels sont les risques réels et quelle est la meilleure façon de procéder pour y mettre fin.

Eclipse Jetty a-t-il atteint sa fin de vie ?

Oui, et le calendrier comporte davantage d’éléments variables que la plupart des équipes ne l’ont remarqué. Jetty 10 et 11 ont atteint la fin du support communautaire le 1er janvier 2024 et ont été déclarés en fin de vie à compter de janvier 2025. Jetty 9 a perdu le soutien de la communauté le 1er juin 2022 et devait arriver en fin de vie en janvier 2025, bien que des versions de sécurité financées par les clients aient continué à être publiées jusqu'à la version 9.4.58.v20250814, sortie en août 2025.

La date qui modifie votre évaluation des risques est plus récente. Depuis le 1er janvier 2026, Webtide et le projet Jetty ne publient plus les versions 9, 10 ou 11 de Jetty sur Maven Central ni sur aucun autre référentiel public. Ainsi, lorsqu’un CVE est publié aujourd’hui concernant une version antérieure à la version 12, il existe souvent une version corrigée. Mais celle-ci n’est tout simplement pas accessible depuis votre environnement de compilation.

Les versions 12.0 et 12.1 de Jetty sont les seules à bénéficier d'un support de la communauté, et la version 12.0 est en fin de vie.

Remarque : Jetty 9 est la version la plus susceptible d'être exécutée dans votre environnement sans que personne n'ait décidé de l'installer. Les versions d' Apache Solr, Spark, ActiveMQ et Hadoop sont toutes fournies avec Jetty intégré, et le plugin Maven de Jetty l'intègre dans les builds ; il a donc tendance à être inclus dans la compilation en tant que dépendance groupée ou transitive plutôt que par choix délibéré.

Principales versions et dates d'Eclipse Jetty

Le tableau de correspondance entre versions et statuts est ce dont la plupart des lecteurs ont réellement besoin ; vous le trouverez donc ci-dessous, à jour en juillet 2026 et tiré des annonces officielles et listes de versions d’Eclipse Jetty.

Une précision concernant cette deuxième colonne : il existe des numéros de version fixes plus élevés pour les lignes de produits en fin de vie, notamment 9.4.60 et versions ultérieures, 10.0.28 et versions ultérieures, ainsi que 11.0.28 et versions ultérieures. Ces versions ne sont pas publiées sur Maven Central, ce qui explique pourquoi le tableau s'arrête à cet endroit.

Comment vérifier si vous utilisez une version d'Eclipse Jetty en fin de vie (EOL)

Il existe deux cas de figure qui nécessitent des vérifications différentes. La version autonome de Jetty est facile à repérer. C'est avec la version intégrée de Jetty que les équipes se cassent les dents.

Si vous exécutez Jetty en tant que serveur autonome, interrogez-le directement :

java -jar $JETTY_HOME/start.jar –version

Cela affiche la version exacte de la compilation, par exemple jetty-12.1.11. Vous pouvez également consulter le fichier VERSION.txt dans le répertoire d'installation de Jetty.

Si Jetty est intégré à une application Spring Boot, à une instance Solr ou à n'importe quel fichier JAR « fat », sa version est masquée dans votre arborescence de dépendances. Pour Maven :

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

Conservez le caractère générique final. Jetty 12 publie ses artefacts d'environnement sous des identifiants de groupe distincts, tels que org.eclipse.jetty.ee10, et un filtre de correspondance exacte de type org.eclipse.jetty ne les fera pas apparaître. Si vous préférez ne pas vous prendre la tête avec la syntaxe du filtre, utilisez mvn dependency:tree | grep -i jetty permet de tout récupérer.

Pour Gradle :

./gradlew dependencies | grep -i jetty

Et pour détecter les fichiers JAR de Jetty présents sur le disque au sein d'autres produits :

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

Indiquez-y le répertoire racine d'une application réelle plutôt que / si l'hôte comporte des montages volumineux ou en réseau, et n'oubliez pas qu'un fichier JAR contenu dans un « fat JAR » ou une couche de conteneur n'apparaîtra pas du tout comme un fichier distinct.

Si le résultat affiche 9.x, 10.x ou 11.x, cela signifie que vous utilisez une version EOL de Jetty. S'il affiche 12.0.x ou 12.1.x, vous utilisez une version prise en charge, mais sachez que les mises à jour de la version 12.0 ne seront plus disponibles cette année.

Que se passe-t-il si vous continuez à utiliser Eclipse Jetty, dont la prise en charge a pris fin ?

Le risque n'est pas purement théorique, et il ne se limite pas à la version visible. Il se divise en trois volets : les nouvelles vulnérabilités CVE dont les correctifs ne sont jamais intégrés à un dépôt public, la longue série de bogues liés à l'analyse HTTP de Jetty, et les failles de sécurité mises en évidence lors d'audits qui découlent de l'utilisation de logiciels dont le support a pris fin.

Nouvelles vulnérabilités CVE pour lesquelles aucun correctif n'a été rendu public

Une vulnérabilité révélée aujourd’hui concernant Jetty 9, 10 ou 11 ne fera l’objet d’aucune publication sur Maven Central. C’est là la conséquence concrète du changement prévu pour janvier 2026, et ce problème est plus étrange qu’il n’y paraît à première vue, car un correctif existe généralement.

CVE-2026-2332 en est un exemple clair. Il s'agit d'une faille de « request smuggling » HTTP dans l'analyseur d'encodage de transfert par morceaux de Jetty : Jetty termine l'analyse de l'extension de morceau à un CRLF situé à l'intérieur d'une chaîne entre guillemets au lieu de la traiter comme une erreur, ce qui permet à un attaquant de désynchroniser Jetty d'un proxy frontal. Publiée le 14 avril 2026, CVSS 7,4, cette vulnérabilité affectait les versions 9.4.0 à 9.4.59, de la 10.0.0 à la 10.0.27, de la 11.0.0 à la 11.0.27, de la 12.0.0 à la 12.0.32 et de la 12.1.0 à la 12.1.6. Les correctifs publics ont été intégrés dans les versions 12.0.33 et 12.1.7. Il existe également des versions corrigées pour les branches en fin de vie (EOL), telles que 9.4.60, 10.0.28 et 11.0.28, mais elles ne sont pas disponibles sur Maven Central. Les avis de sécurité de Jetty le précisent désormais, indiquant que les correctifs EOL sont disponibles auprès de fournisseurs commerciaux, notamment TuxCare.

Puis cela s'est reproduit. La vulnérabilité CVE-2026-5795, un contournement de l'authentification JASPI dû à la persistance de l'état ThreadLocal après un retour anticipé, a été corrigée publiquement dans les versions 12.0.34 et 12.1.8, les versions 9.4.61, 10.0.29 et 11.0.29 n'étant disponibles que via ces mêmes canaux de support étendu. Deux avis de sécurité de gravité élevée en un seul printemps, tous deux corrigés, mais aucun correctif n'est accessible à partir d'une version publique si vous utilisez une version antérieure à la 12.

Une application Spring Boot 2.7 intégrant Jetty 9.4 illustre bien ce piège. La remplacement de la version de Jetty dans votre build ne fonctionne que s’il existe une version publique vers laquelle effectuer ce remplacement, ce qui n’est plus le cas pour la version 9.4. L'alternative consiste à utiliser un artefact de la version 12.x, ce qui implique le JDK 17, les espaces de noms Jakarta et une mise à niveau majeure de Spring Boot ; par conséquent, la vulnérabilité CVE a tendance à rester dans le rapport. Le correctif existe ; le plus difficile est d'obtenir une version prise en charge pour vos serveurs, et combler cette lacune sans mise à niveau forcée, c'est précisément le rôle des correctifs fournis par les éditeurs.

Bilan de Jetty en matière d'analyse HTTP

La gestion des requêtes HTTP/1.x constitue une faille récurrente de Jetty, et ce schéma se répète suffisamment souvent pour qu'on puisse s'y préparer. La vulnérabilité CVE-2026-2332 est un bug d'analyse de l'encodage par blocs, et c'est loin d'être le premier. Le CVE-2023-40167 concernait Jetty qui acceptait un + avant le valeur de Content-Length , une anomalie d'analyse qui peut permettre le « request smuggling » lorsqu'un front-end interprète cet en-tête différemment.

La série de 2017 illustre ce même problème à travers trois failles liées à l'analyseur syntaxique. CVE-2017-7656 concernait l'acceptation d'une ligne de requête de type HTTP/1 déclarant HTTP/0.9, ce qui pouvait corrompre un cache lorsqu'un intermédiaire transférait la version sans la traiter. CVE-2017-7657 était un débordement d'entier lors de l'analyse de la longueur d'un chunk, ce qui permettait à un gros chunk d'être lu comme s'il était plus petit et à son corps d'être traité comme une requête en pipeline. CVE-2017-7658 concernait un conflit entre les indicateurs « Content-Length » et d’encodage par blocs. Dans les deux derniers cas, le scénario critique se produisait lorsque Jetty était situé derrière un intermédiaire qui imposait une autorisation et transmettait la requête sans la modifier : la requête introduite clandestinement arrivait ainsi au-delà de ce contrôle.

Deux conclusions s'imposent à la lumière de ces antécédents. Si Jetty est placé derrière un proxy, un équilibreur de charge ou un CDN, considérez les CVE liés au parseur comme hautement prioritaires plutôt que comme des problèmes purement théoriques, car c'est l'intermédiaire qui rend ces failles exploitables. Et si vous ne pouvez pas appliquer de correctif immédiatement, la normalisation ou la suppression des extensions de chunks au niveau du front-end constitue une véritable mesure d'atténuation provisoire pour ce type de bogue.

Intégration cachée et exposition aux risques de non-conformité

Le problème de dépendance transitive complique encore davantage tout ce qui précède. Étant donné que certaines versions de Solr, Spark, ActiveMQ et Hadoop intègrent Jetty, et que le plugin Maven de Jetty l’intègre dans les builds, l’hypothèse selon laquelle « nous n’utilisons pas Jetty » est souvent erronée. Dans un portefeuille de grande envergure, il est courant de trouver plusieurs versions majeures de Jetty réparties entre différents services, chacune présentant ses propres risques et ayant son propre responsable.

Il y a également l'aspect audit. La norme PCI DSS définit des exigences explicites en matière de correctifs et de gestion des vulnérabilités, FedRAMP exige que les délais d'analyse et de correction soient documentés, et bien que SOC 2 constitue une attestation relative aux contrôles que vous avez définis plutôt qu’une obligation de correctifs, un auditeur vous demandera tout de même comment un serveur HTTP non pris en charge s’inscrit dans les contrôles que vous avez consignés. Un Jetty en fin de vie (EOL) n’entraîne pas à lui seul un échec à l’audit. Il vous oblige toutefois à vous justifier, et « le correctif en amont n’est plus publié » est une mauvaise réponse si elle n’est pas étayée par un contrôle compensatoire.

Attention : Une analyse des dépendances « verte » de vos dépôts d'applications ne signifie pas que vous êtes tiré d'affaire. Jetty en fin de vie se cache le plus souvent dans des produits tiers que vous avez déployés sous la forme d'un artefact unique ; ainsi, le fichier JAR vulnérable peut ne jamais apparaître comme une dépendance directe dans votre propre fichier pom.xml. Analysez les artefacts déployés et les images de conteneur, et pas seulement les référentiels que vous créez.

Parcours de mise à niveau : passage à Eclipse Jetty 12

La procédure de migration dépend fortement du fait que votre instance Jetty soit autonome ou intégrée. Chaque étape ci-dessous conditionne la suivante ; l'ordre dans lequel vous les effectuez est donc important.

•   Commençons par le JDK 17. Jetty 12.0 et 12.1 définissent tous deux Java 17 comme version minimale du runtime. Si vous utilisez Java 8 ou Java 11, c'est l'étape décisive et généralement la tâche la plus importante.
•   Sélectionnez ensuite votre environnement EE. Jetty 12 exécute les applications au sein de modules spécifiques à chaque environnement : la version 12.0 intègre EE8, EE9 et EE10, tandis que la version 12.1 couvre EE8 à EE11. EE10 utilise jakarta.servlet (Servlet 6.0) et EE11 utilise Servlet 6.1 ; le code et les bibliothèques important les API javax.* de Java EE doivent donc être adaptés à ces cibles. EE8 conserve l'espace de noms javax.*, ce qui signifie que vous pouvez d'abord déployer le cœur de Jetty 12 et planifier la mise à jour de l'espace de noms séparément. Il convient de le préciser clairement pour toute personne chargée de la mise en œuvre : seuls les paquets Java EE ont été déplacés. javax.crypto, javax.sql et le reste de Java SE restent exactement où ils sont.
•   Compatibilité entre les versions de Spring Boot pour les utilisateurs de Jetty embarqué. C'est là que réside le piège. Jetty 12 embarqué nécessite Spring Boot 3.2 ou une version ultérieure, car Spring Boot 3.0 et 3.1 étaient fournis avec Jetty 11 et exigeaient de rétrograder l'API Servlet à la version 5.0 pour pouvoir utiliser Jetty. Spring Boot 3.x nécessite quant à lui Java 17 et l'espace de noms Jakarta EE 9 ; ainsi, une demande de « mise à niveau de Jetty » se transforme en une migration de Spring Boot 2 vers 3, avec une version minimale de 3.2.

Prenons l'exemple d'une application SaaS sous Spring Boot 2.7 avec Jetty 9.4 intégré. La mise à niveau de Jetty ne se résume pas à une simple ligne dans le fichier pom.xml. Il s’agit d’un projet s’étalant sur plusieurs sprints et touchant au JDK, aux importations Java EE dans l’ensemble du code source, à la configuration de Spring Security, ainsi qu’à une longue liste de bibliothèques nécessitant des versions compatibles avec Jakarta.

La décision est claire. Si vous utilisez Jetty en mode autonome et que vous êtes déjà sous Java 17, la migration est moins complexe que dans le cas d’une version intégrée, mais prévoyez du temps pour passer en revue les artefacts Maven renommés, la nouvelle structure des modules et des environnements, votre configuration « jetty-base » et vos descripteurs de déploiement. Si Jetty est intégré à une application Spring Boot 2.x, planifiez d’abord la migration vers Spring Boot 3.2 ou une version ultérieure et considérez la mise à jour de la version de Jetty comme une conséquence en aval. Et si vous travaillez déjà avec un migration vers la fin de vie (EOL) , enchaînez les deux, car les travaux liés à Jakarta se recoupent presque entièrement.

Conseil d'expert : Eclipse Transformer permet de remplacer automatiquement les références javax.* par jakarta.* dans le bytecode des dépendances que vous ne pouvez pas recompiler à partir du code source. Cela évite beaucoup de tâches répétitives, mais les artefacts transformés doivent faire l'objet de tests de régression complets et ne seront pas pris en charge par le fournisseur d'origine. Considérez donc cette solution comme une solution temporaire pour une dépendance bloquée plutôt que comme une stratégie de migration.

Vos options si vous ne pouvez pas effectuer la mise à niveau pour le moment

Il arrive parfois que la migration ne puisse pas avoir lieu ce trimestre. Le travail lié à Spring Boot 3 est trop important, ou bien le produit d'un fournisseur utilise une ancienne version de Jetty sur laquelle vous n'avez aucun contrôle. Il vous reste toutefois trois options réalistes : bénéficier d'un support étendu assuré par le fournisseur, gérer vous-même les backports en interne, ou remplacer Jetty.

1. Utilisez le support à vie « Endless Lifecycle Support » de TuxCare pour Jetty

Si la migration n'est prévue que dans plusieurs mois, le support étendu assuré par le fournisseur permet de continuer à appliquer les correctifs à Jetty en fin de vie sans vous obliger à effectuer la mise à niveau avant l'échéance prévue. Le support « Endless Lifecycle » de TuxCare fournit des correctifs de sécurité pour les logiciels open source en fin de vie, et sa couverture de Jetty s’étend aux versions 7, 8, 9.2, 9.4, 10 et 11, y compris les versions post-fin de vie qui corrigent les CVE de 2026 : 9.4.60 et versions ultérieures, 10.0.28 et versions ultérieures, et 11.0.28 et versions ultérieures. Webtide s’est associé à TuxCare pour proposer ce service, ce qui explique pourquoi les avis de sécurité de Jetty orientent désormais les utilisateurs dont la version a atteint la fin de vie vers des fournisseurs de correctifs commerciaux.

La mise à disposition s'intègre à la chaîne d'outils dont vous disposez déjà. Les artefacts corrigés sont publiés sous forme de paquets signés dans un registre géré par TuxCare et compatible avec Maven. Ainsi, les processus de compilation Maven et Gradle existants peuvent les utiliser simplement en pointant vers un autre référentiel et en mettant à jour la version, sans avoir à modifier votre processus de compilation.

L'empreinte de Jetty est réduite et épurée : jetty-server utilise jetty-http, jetty-io, jetty-utilet slf4j-api. Le problème, c’est l’attribution des CVE. jetty-http et jetty-server sont précisément les modules où se trouvent les failles de « request smuggling » et d’analyse d’URI, et jetty-http est généralement l’artefact que votre scanner signale après avoir descendu trois niveaux à travers d’autres composants. ELS couvre les dépendances directes et transitives sans coût supplémentaire, de sorte que les modules qui contiennent réellement les vulnérabilités de Jetty sont corrigés, et pas seulement l’artefact que vous avez déclaré.

Pour la plupart des équipes, il s'agit d'une solution de transition pragmatique. Elle permet d'alléger la pression immédiate en matière de sécurité et vous offre une couverture documentée des correctifs à présenter lors d'un audit, tout en vous laissant le temps de planifier correctement la mise en œuvre de Java 17 et de Spring Boot 3.2, au lieu de devoir réécrire les intégrations de serveurs web embarqués en fonction des délais imposés par un tiers.

2. Gestion interne de Jetty

Vous pouvez créer une branche dérivée de la dernière version publique de Jetty et intégrer vous-même les correctifs de sécurité. C'est techniquement possible, et cela peut parfois s'avérer la bonne solution pour un déploiement fortement personnalisé qui, de toute façon, n'aurait jamais pu être migré sans heurts.

Cela représente également un coût important à bien des égards : vous devenez responsable de la maintenance de votre propre fork de Jetty. Quelqu’un doit surveiller chaque nouvelle alerte, lire attentivement le parseur HTTP/1.x afin de porter correctement un correctif de contournement, puis le intégrer à votre processus de compilation et de publication en s’assurant qu’il a fait l’objet de tests de régression. Si vous commettez une erreur de nuance lors d’un correctif du parseur, vous déployez un patch qui semble appliqué mais qui ne l’est pas, ce qui est pire que de savoir que vous êtes vulnérable. Maintenir cela nécessite des compétences dédiées en ingénierie de sécurité et en gestion des versions que la plupart des équipes applicatives ne disposent pas en réserve.

3. Remplacer Jetty par une autre solution

Le remplacement de Jetty par un autre conteneur de servlets est une option envisageable, surtout si vous envisagiez de toute façon de modifier votre architecture. Tomcat et Undertow constituent des alternatives équivalentes, et pour un déploiement autonome avec des besoins simples en matière de servlets, Tomcat est l’un des choix les plus courants. Netty représente une approche différente : il s’agit d’un framework réseau asynchrone de bas niveau plutôt que d’un conteneur de servlets ; passer à Netty implique donc une refonte architecturale, et non un simple remplacement.

Soyez réaliste quant à l’ampleur de la tâche. Pour une application embarquée, remplacer le serveur implique souvent davantage de travail que la mise à niveau de Jetty : un modèle de configuration différent, un réglage différent des connecteurs et du pool de threads, ainsi qu’une nouvelle série de tests de charge. Un remplacement qui « devrait être équivalent » a tendance à faire apparaître des différences de comportement dans des cas limites sous le trafic de production. Et si vous êtes déjà en train de migrer vers Jetty 12 via Jakarta, la majeure partie de ce travail est réutilisable, ce qui fait que rester sur Jetty est la solution la plus simple pour de nombreuses équipes.

Assurez la sécurité d'Eclipse Jetty en fin de vie (EOL) avec TuxCare

La question des versions est désormais réglée. Les versions 8, 9, 10 et 11 de Jetty sont en fin de vie ; les publications publiques des séries 9, 10 et 11 ont pris fin le 1er janvier 2026, et la migration vers Jetty 12 est un véritable projet, bien plus qu’une simple case à cocher. La question qui reste en suspens est de savoir comment combler le fossé entre aujourd’hui et la fin de la migration.

Si vous pouvez passer à Jetty 12 ce trimestre, faites-le, et planifiez de manière réaliste la mise en œuvre du JDK 17 et de Spring Boot 3.2. Si ce n’est pas possible, n’utilisez pas de versions non corrigées, car des versions corrigées pour les lignes de produits en fin de vie (EOL) existent bel et bien, mais ne sont tout simplement plus publiées. Le support assuré par le fournisseur permet de corriger les vulnérabilités connues et vous apporte la garantie d’un processus de correction actif pendant que vous planifiez votre transition. Découvrez comment TuxCare gère les logiciels open source en fin de vie, et consultez tarifs pour évaluer leur adéquation avec votre portefeuille.

FAQ

Quelles versions d'Eclipse Jetty sont encore prises en charge ?

Seules les versions 12.0 et 12.1 de Jetty bénéficient d'un support communautaire. Jetty 12.1 est la version actuelle et fait l'objet de correctifs réguliers ; la version 12.0 continue de recevoir des mises à jour, mais Webtide a indiqué que celles-ci prendraient fin courant 2026, sans toutefois s'engager sur une date précise. Toutes les versions antérieures, y compris Jetty 8, 9, 10 et 11, sont en fin de vie.

Peut-on encore utiliser Eclipse Jetty 9 en toute sécurité en environnement de production ?

Pas sans une source active de correctifs de sécurité. Jetty 9.4 est en fin de vie ; sa dernière version publique était la 9.4.58.v20250814, sortie en août 2025, et depuis le 1er janvier 2026, aucune version 9.x n’est publiée sur Maven Central. Il existe des versions corrigées plus récentes, mais uniquement auprès de fournisseurs proposant une assistance prolongée ; par conséquent, utiliser la version 9.4 de manière responsable implique de disposer de cette assistance, ou de mettre en place des contrôles compensatoires en amont, ainsi qu'un plan de migration pour les deux.

Comment savoir si mon application Spring Boot utilise une version de Jetty en fin de vie ?

Exécuter mvn dependency:tree -Dincludes=’org.eclipse.jetty*’ ou ./gradlew dependencies | grep -i jetty. Conservez le caractère générique, car Jetty 12 publie des artefacts d’environnement sous des identifiants de groupe tels que org.eclipse.jetty.ee10, qu’un filtre à correspondance exacte ne détectera pas. Si la sortie affiche un artefact Jetty 9.x, 10.x ou 11.x, votre application se trouve sur une ligne en fin de vie (EOL), même si Jetty est apparu en tant que dépendance transitive que vous n’avez jamais déclarée.

La mise à niveau de Jetty 10 vers Jetty 12 nécessite-t-elle une migration de « javax » vers « jakarta » ?

Uniquement si vous ciblez l'environnement EE10 ou EE11 de Jetty 12. Jetty 10 utilise javax.servlet, EE10 utilise jakarta.servlet (Servlet 6.0) et EE11 utilise Servlet 6.1. Jetty 12 propose également les environnements EE8 et EE9, et EE8 conserve l'espace de noms javax.* ; vous pouvez donc commencer par migrer le cœur de Jetty et le JDK, puis traiter la migration de l'espace de noms comme un projet à part entière.

Quelle version du JDK est requise pour Eclipse Jetty 12 ?

Java 17. Les versions 12.0 et 12.1 de Jetty imposent Java 17 comme version minimale du runtime ; la mise à niveau du JDK constitue donc la première étape incontournable pour toute équipe utilisant actuellement Jetty 9, 10 ou 11 sous Java 8 ou Java 11.

Résumé

Nom de l'article

Fin de vie d'Eclipse Jetty : versions, procédure de mise à niveau et options

Description

Les versions Jetty 8, 9, 10 et 11 ont atteint leur fin de vie, et leur publication a cessé en janvier 2026. Découvrez les dates de sortie, les commandes de détection et les options qui s'offrent à vous.

Auteur

Rohan Timalsina

Nom de l'éditeur

de TuxCare

Logo de l'éditeur