Fin de vie d'OpenJDK 17 : dates clés, options disponibles et assistance

Principaux enseignements

• OpenJDK 17 n'a pas de date de fin de vie précise, et le support technique assuré par les éditeurs s'étend de septembre 2026 à octobre 2029 au moins.
• Une fois le support terminé, les correctifs CVE ne sont plus fournis et il devient plus difficile de passer les audits de conformité et d'obtenir le renouvellement des contrats d'assurance.
• Les équipes qui ne sont pas prêtes à migrer peuvent continuer à bénéficier des correctifs CVE grâce à un support étendu proposé par des tiers, sans avoir à modifier leur environnement d'exécution ni leur code.

Si vos environnements de production fonctionnent encore sous OpenJDK 17, vous n’êtes pas le seul. Java 17 était le choix LTS « sûr » pour une bonne raison : stable, bien pris en charge et largement compatible. Le problème, c’est que la notion de « prise en charge » revêt désormais une signification différente selon la distribution que vous utilisez, et que les dates ne coïncident pas.

Cet article explique ce que signifie concrètement la fin de vie (EOL) d'OpenJDK 17, présente les dates précises pour les versions les plus courantes, explique pourquoi la migration est plus difficile qu'il n'y paraît dans la documentation, et présente les options qui s'offrent réellement à vous lorsque la date butoir approche alors que le code n'est pas encore prêt.

Présentation du cycle de vie et du support d'OpenJDK

OpenJDK est l'implémentation de référence open source de Java SE, gérée par Oracle. Mais ce n'est pas la même chose que « Oracle JDK » – et c'est précisément cette distinction qui rend la planification de la fin de vie (EOL) si déroutante.

La communauté OpenJDK en amont assure le support d'une version majeure pendant environ six mois, jusqu'à la sortie de la prochaine version fonctionnelle. Le support à long terme relève de l'aval et est géré par les éditeurs qui créent leurs propres versions et y appliquent des correctifs. Depuis que Java est passé à un rythme de publication de six mois, seules certaines versions bénéficient du statut LTS. Java 17 en fait partie. Java 21 et Java 25 sont des versions LTS plus récentes.

Voici où en sont actuellement les versions LTS :

L'adoption reste encore bien en deçà de ces dates. Le rapport 2025 sur la productivité des développeurs Java publié par JRebel révèle que 61 % des personnes interrogées utilisent encore Java 17. Sur l’ensemble de l’échantillon, 72 % ont déclaré utiliser des distributions Oracle ne bénéficiant plus du support public gratuit, dont 35 % sur Java 8 et 32 % sur Java 11. Il y a de fortes chances que votre équipe gère au moins une version en fin de vie (EOL) parallèlement à la version vers laquelle vous prévoyez de migrer.

Dates clés d'OpenJDK 17

Ce qu'il faut avant tout retenir : il n'y a pas de date unique de fin de vie (EOL) pour OpenJDK 17. Chaque distribution suit son propre calendrier.

Les deux dates que la plupart des équipes devraient garder à l'esprit en ce moment sont la fin du support « Premier Support » d'Oracle en septembre 2026 et celle de Red Hat en décembre 2027. Si vous utilisez Oracle JDK 17 sans abonnement « Universal Subscription », les mises à jour de sécurité gratuites ont pris fin en septembre 2024. Pour continuer à bénéficier de ces mises à jour, vous devez souscrire à un abonnement payant « Oracle Java SE Universal Subscription ».

Pour une analyse détaillée des différences entre les versions Oracle et OpenJDK en matière de licence et de support, consultez notre guide « OpenJDK vs Oracle JDK ».

Java 17 était la version LTS lancée au moment où Oracle a annoncé le passage à un cycle LTS de deux ans ; à partir de Java 21, l'intervalle entre les versions LTS est passé de trois ans à deux. Ce cycle plus court signifie que les entreprises sont désormais confrontées à une pression de mise à niveau tous les deux ans au lieu de tous les trois ans, mais les calendriers de migration de la plupart des équipes n'ont pas été adaptés en conséquence.

Que se passe-t-il réellement lorsque OpenJDK 17 arrive en fin de vie ?

Votre JVM continue de fonctionner. C’est justement cela qui incite les équipes à ignorer les dates de fin de vie : rien ne tombe en panne dès le premier jour. L’application qui fonctionnait parfaitement hier semble exactement identique demain. Ce qui change, c’est ce qui se passe en amont. Ou plus précisément, ce qui cesse de se produire.

Trois éléments commencent à faire monter le risque en arrière-plan après la fin de vie du produit.

1. Fin des correctifs de sécurité

C'est là le plus important. Après la fin de vie (EOL), le responsable de la maintenance cesse d'intégrer les correctifs CVE à votre version. Les nouvelles vulnérabilités découvertes dans les composants internes de la JVM, la bibliothèque standard, les implémentations TLS ou les chemins de désérialisation ne seront pas corrigées dans votre version. Elles seront corrigées dans Java 21 et 25. Votre version, quant à elle, restera telle quelle.

La JVM n'est pas une cible négligeable. Au cours de la dernière décennie, Java a été impliqué dans certaines des catégories de vulnérabilités les plus activement exploitées, et de nouveaux CVE apparaissent à chaque cycle trimestriel de mise à jour critique (Critical Patch Update). Dès que votre version ne figure plus sur cette liste, vous accumulez toutes les failles non corrigées qui apparaissent entre la fin de vie (EOL) et le moment où vous achevez enfin la migration.

2. La mise en conformité devient plus difficile

La plupart des référentiels de conformité – PCI DSS, HIPAA, SOC 2, FedRAMP, ISO 27001 – comportent des exigences explicites ou implicites concernant l'utilisation de logiciels pris en charge et dotés des derniers correctifs. Les auditeurs se montrent de plus en plus précis sur ce point, et « nous avions prévu de procéder à la mise à jour » ne constitue pas une réponse satisfaisante dans un rapport d'audit.

L'utilisation d'une version Java en fin de vie vous expose aux risques suivants :

• Échecs des analyses automatisées de vulnérabilités: Nessus, Qualys, Wiz et d'autres outils similaires signalent par défaut les environnements d'exécution en fin de vie (EOL)
• Consacrer du temps supplémentaire à consigner et à justifier les exceptions à chaque cycle d'audit
• Une complication pour les renouvellements d'assurance cyber : plusieurs grands assureurs demandent désormais directement si des logiciels en fin de vie sont utilisés en production
• Prétendre que la divulgation d'une faille a été motivée par le fait que « nous savions que cela n'était pas justifié » est une explication très difficile à faire valoir après un incident

État des lieux : Le rapport DBIR 2025 de Verizon a révélé que l’exploitation des vulnérabilités comme vecteur d’accès initial a augmenté de 34 % d’une année sur l’autre, représentant désormais 20 % des violations de données. C’est précisément là que se situent les environnements d’exécution non mis à jour.

3. La dégradation des dépendances est un problème qui évolue lentement

C'est là que les équipes qui pensent avoir déjà tout prévu se font prendre au dépourvu. Même si votre environnement d'exécution Java reste à la version 17, le reste de votre pile ne s'arrête pas pour autant.

Les frameworks cessent de prendre en charge les anciens JDK. Spring Boot publie une nouvelle version majeure chaque année et revoit régulièrement à la hausse son niveau de référence. Les responsables de la maintenance des bibliothèques cessent de tester leurs produits sur les JVM en fin de vie. Les images de base des conteneurs sont reconstruites pour fonctionner avec des JDK plus récents. À un moment donné, vous êtes confronté à une mise à jour de dépendance où une bibliothèque transitive nécessite une fonctionnalité qui n’existe qu’à partir de Java 21, et la mise à niveau que vous repoussiez depuis deux ans doit soudainement être effectuée lors de ce sprint – au pire moment possible.

Pourquoi la mise à niveau n'est pas toujours simple

Le passage de Java 17 à la version 21 ou 25 se fait véritablement plus en douceur que la plupart des migrations vers une nouvelle version majeure effectuées par le passé. Cela ne signifie pas pour autant que ce soit bon marché. C'est là que les équipes se retrouvent souvent bloquées.

Vos dépendances ne sont pas toutes prêtes

Une mise à niveau de la version Java ne se résume pas à un simple remplacement de la JVM. Elle concerne toutes les bibliothèques, tous les frameworks et tous les artefacts internes qui sont liés à un niveau de bytecode spécifique ou qui s'appuient sur des mécanismes internes ayant évolué d'une version à l'autre.

Parmi les pannes courantes sur le trajet 17 → 21, on peut citer :

• Les bibliothèques faisant un usage intensif de la réflexion se heurtent à des règles d'encapsulation plus strictes
• Les anciens outils de manipulation de bytecode – ASM, certaines versions de Byte Buddy, les anciennes versions de Hibernate – nécessitent des mises à jour importantes
• Code utilisant sun.misc.Unsafe rencontrer des avertissements de dépréciation ou des API purement et simplement supprimées
• Outils de build (Maven Surefire, Gradle, JaCoCo) nécessitant des mises à jour de version synchronisées
• Images de conteneurs et exécuteurs de CI nécessitant des mises à jour parallèles

Une équipe travaillant sur un monolithe vieux de quatre ans ne se rendra généralement compte de tout cela qu’une fois que la branche de mise à jour aura été intégrée dans le système de CI. Prévoyez un budget pour cela.

Votre couverture de test n'est probablement pas aussi bonne que vous le pensez

Les mises à jour de la JVM font apparaître des bogues que les tests unitaires ne détectent pas. Le comportement du ramasse-miettes varie d’une version à l’autre. Les paramètres par défaut changent. Le compilateur JIT prend des décisions différentes. La gestion des paramètres régionaux, celle des fuseaux horaires, le comportement du moteur d’expressions régulières : tous ces éléments ont provoqué de véritables incidents en production lors de mises à jour précédentes.

Si votre suite de tests ne simule pas l'utilisation de bases de données réelles, d'opérations d'E/S réelles et de profils de charge réalistes, la mise à niveau réussira les tests d'intégration (CI) mais échouera en production. C'est la partie du plan de migration qui est souvent discrètement négligée, et c'est la cause de la plupart des analyses a posteriori du type « on a déjà effectué la mise à niveau, pourquoi tout ne fonctionne-t-il plus ? ».

Le calendrier ne correspond pas au code source

Même lorsque la migration technique est gérable, la réalité organisationnelle ne l’est souvent pas. Les ressources techniques sont allouées trimestre après trimestre. La mise à niveau entre en concurrence avec le développement de nouvelles fonctionnalités, le retard accumulé en matière de sécurité et tout incident qui retient l’attention de l’équipe cette semaine-là. Une migration estimée à trois mois sur le papier se transforme en réalité en une migration de neuf mois, car personne ne peut y consacrer du temps sans interruption.

Sur le terrain : Un scénario classique : une équipe prévoit la mise à niveau de Java 17 vers Java 21 pour le premier trimestre, se heurte à un conflit de version majeure de Spring Boot, reporte le projet au deuxième trimestre, se retrouve prise dans un cycle de préparation à l’audit SOC 2, et tout cela se repousse au quatrième trimestre. À ce moment-là, Java 25 est disponible et l’objectif change à nouveau. Les équipes qui respectent réellement leurs délais considèrent les dates de fin de vie (EOL) comme des jalons fixes du projet, attribués à des responsables désignés – et non comme des tâches en attente auxquelles elles s’attaqueront « un jour ou l’autre ».

Vos options après la fin de vie d'OpenJDK 17

Il n'y a pas de réponse unique. La meilleure approche dépend de vos capacités techniques, du degré de rigidité de votre pile technologique et du niveau d'exigence de vos obligations de conformité. Voici les options réalistes.

Option 1 : Support étendu par un tiers pour OpenJDK 17

Si une mise à niveau n’est pas envisageable dans vos délais actuels, le support tiers à cycle de vie prolongé constitue la solution la plus simple pour continuer à recevoir les correctifs CVE sans modifier votre environnement d’exécution ni refactoriser votre code. Cette approche s’avère particulièrement efficace pour les équipes utilisant OpenJDK 17 sur un ensemble hétérogène de distributions Linux (RHEL, AlmaLinux, Rocky, Ubuntu, Debian), où les cycles de vie de support des systèmes d’exploitation et ceux du JDK ne coïncident pas parfaitement.

Le service « Endless Lifecycle Support » de TuxCare pour OpenJDK fournit des correctifs de sécurité continus pour les versions 17, 11, 8 et 7 d’OpenJDK, couvrant ainsi la plupart des principales distributions Linux d’entreprise. L’approche est simple : vous conservez vos versions existantes, vous continuez à recevoir des correctifs à mesure que de nouvelles vulnérabilités (CVE) apparaissent, et vous gagnez du temps pour planifier une véritable migration plutôt qu’une migration précipitée. Ce service est spécialement conçu pour les équipes soumises à des contraintes réglementaires qui ne peuvent tolérer l’exécution de runtimes non corrigés, mais qui ne peuvent pas non plus tout laisser tomber pour procéder à une mise à niveau majeure de version au cours de ce trimestre.

Option 2 : Passer à Java 21 ou Java 25

La solution idéale à long terme pour la plupart des équipes. Si vous disposez des ressources techniques nécessaires, la mise à niveau vers une version LTS actuelle vous garantit plusieurs années de support public gratuit, des améliorations significatives en termes de performances et une compatibilité continue avec l’écosystème à mesure qu’il évolue. Selon la feuille de route de support d’Oracle, Java 21 bénéficie d’un support Premier jusqu’en septembre 2028 et Java 25 jusqu’en septembre 2030. Toutefois, si vous utilisez Corretto, Temurin ou une autre version, vérifiez le calendrier spécifique de votre fournisseur.

C'est la bonne décision à prendre lorsque :

• Votre base de code est suffisamment petite ou a fait l'objet de tests suffisamment poussés pour permettre une migration en l'espace d'un trimestre
• Votre couverture CI permettra en effet de détecter les changements de comportement, et pas seulement les échecs de compilation
• Vos principales dépendances prennent déjà en charge Java 21 et les versions ultérieures.
• Vous pouvez mettre en place un sprint d'ingénierie ciblé sans qu'il soit tiraillé dans trois directions différentes

Option 3 : Passer à une autre distribution OpenJDK

Si vous utilisez Oracle JDK 17 et que le changement de licence prévu en septembre 2024 vous a pris au dépourvu, vous n’avez pas besoin de migrer vers Java 21 dès maintenant pour éviter ce problème de licence. Vous pouvez passer à Eclipse Temurin, Amazon Corretto ou à la version Microsoft de l’OpenJDK sans modifier votre code Java : ces solutions sont toutes certifiées TCK et présentent un comportement identique pour la grande majorité des charges de travail.

La migration hors du JDK d’Oracle est déjà en cours depuis quelques années : les données de New Relic montrent que la part de marché d’Oracle sur le marché du JDK est passée de 75 % en 2020 à 21 % en 2024, tandis qu’Eclipse Adoptium a enregistré une croissance de 50 % d’une année sur l’autre. La plupart des équipes qui ont effectué cette migration n’ont pas eu à modifier la moindre ligne de code Java pour y parvenir.

Quelques points à vérifier avant de changer d'opérateur :

• Vérifiez la date de fin de vie (EOL) de la nouvelle distribution pour Java 17 : celles-ci varient entre un et trois ans.
• Vérifiez s'il existe des paramètres ou des extensions JVM spécifiques au fournisseur (c'est rare, mais cela vaut la peine d'être vérifié)
• Mettre à jour le provisionnement, les images de conteneurs et l'intégration continue (CI) afin qu'ils s'alimentent à partir de la nouvelle source
• Consigner la modification dans les registres de conformité

Attention : Changer de distribution est une stratégie à court terme, pas une solution à long terme. Corretto 17 et la version de Microsoft prolongent dans certains cas la prise en charge au-delà de la période prévue par Red Hat, mais toutes ces versions finissent par arriver à terme. Profitez de ce changement pour gagner 12 à 24 mois de marge de manœuvre, mais ne l'utilisez pas comme prétexte pour cesser de planifier la migration proprement dite.

Option 4 : Accepter le risque (de manière délibérée)

Certaines équipes font véritablement ce choix, et dans certains contextes, cela se justifie. Outils internes, environnements isolés, charges de travail jetables… Tout ne justifie pas forcément le coût technique lié à un environnement d'exécution mis à jour.

Prenez cette décision en toute connaissance de cause, consignez-la par écrit et segmentez le risque afin qu’aucune JVM non mise à jour ne se retrouve sur un terminal accessible au public. Associez cela à une approche automatisée de gestion des correctifs pour le reste de votre pile, afin que le composant non pris en charge ne devienne pas d’emblée le maillon faible. Par ailleurs, comprenez bien la différence entre la gestion des correctifs et la gestion des vulnérabilités: il ne s’agit pas de la même discipline, et c’est en les confondant que l’on passe à côté des composants non pris en charge.

Sécurisation d'OpenJDK après la fin de vie (EOL) avec TuxCare

La vérité dérangeante concernant la fin de vie (EOL) de Java, c’est que le fait que « le runtime fonctionne toujours » est précisément ce qui incite à ne pas en faire une priorité. Les correctifs cessent d’être publiés, les dépendances se détériorent, les constatations d’audit s’accumulent… puis, un jour, un CVE est publié avec un exploit fonctionnel, et votre version ne figure pas sur la liste des correctifs.

Si votre équipe utilise OpenJDK 17 et que le calendrier de migration prévu sur le papier ne correspond pas à la réalité, ce n’est pas une situation inhabituelle. La mise à niveau est la bonne solution à long terme. Mais s’il vous faut encore un ou deux trimestres avant d’être prêt à la mener à bien, continuer à utiliser une version non mise à jour entre-temps représente un risque réel.

Le support à cycle de vie illimité de TuxCare pour OpenJDK est conçu pour répondre à ce besoin : mêmes versions, mêmes workflows, correctifs CVE qui ne prennent pas fin lorsque le calendrier de support en amont le prévoit. Il couvre les versions 7, 8, 11 et 17 d’OpenJDK sur les systèmes Enterprise Linux et basés sur Debian, aussi longtemps que votre organisation en aura besoin. Consultez les tarifs ou contactez les experts de TuxCare pour définir la couverture adaptée à votre environnement.

Résumé

Nom de l'article

Fin de vie d'OpenJDK 17 : dates clés, options disponibles et assistance

Description

Dates de fin de vie d'OpenJDK 17, calendriers de prise en charge, différences entre les éditeurs et options de mise à niveau. Découvrez ce que signifie « EOL » et comment vous préparer à Java 17.

Auteur

Rohan Timalsina

Nom de l'éditeur

de TuxCare

Logo de l'éditeur