Vous utilisez Java 17 en production depuis des mois, tout fonctionne, et votre équipe se demande si migrer vers Java 21 en vaut la peine. La réponse dépend moins des nouvelles fonctionnalités du langage que de trois paramètres souvent négligés : la distribution du JDK utilisée, le coût de licence et la trajectoire vers Java 25, le LTS suivant.
Licence Oracle, distribution OpenJDK et coût réel d’un upgrade Java
Avant de comparer des fonctionnalités, il faut parler d’argent. Le modèle de licence Oracle peut modifier sensiblement le coût réel du passage à Java 21.
A lire aussi : Comment booster mon PC trop lent ?
Concrètement, une PME et un grand groupe ne paient pas du tout la même facture, même si le nombre de JVM déployées est identique. Pourquoi ce point compte-t-il dans le choix entre Java 17 et 21 ? Parce que rester sur Java 17 avec un support Oracle étendu a un prix, et migrer vers Java 21 sous licence Oracle aussi.
L’alternative la plus courante consiste à utiliser une distribution OpenJDK gratuite. Eclipse Temurin, IBM Semeru ou les builds fournies par les hébergeurs cloud proposent toutes Java 21, mais avec des calendriers de support différents. La durée de support dépend de la distribution, pas du numéro de version. Un Java 21 Temurin et un Java 21 Oracle n’auront pas la même date de fin de maintenance.
A lire aussi : Qu'est-ce que le réseau pod cidr ?
- Eclipse Temurin : maintenu par la communauté Adoptium, gratuit, largement utilisé dans les pipelines CI/CD.
- IBM Semeru : intéressant si vous déployez sur des environnements IBM ou Liberty, avec un calendrier de support propre.
- Oracle JDK : support commercial payant, cycles de mises à jour trimestriels bien documentés.
- Builds cloud (Amazon Corretto, Microsoft Build of OpenJDK) : alignés sur les besoins des plateformes cloud respectives.
Choisir Java 21 sans vérifier quelle distribution vous utilisez, c’est prendre une décision technique sans connaître son impact financier.
Fonctionnalités Java 21 qui changent le code au quotidien
Java 21 n’est pas une simple mise à jour cosmétique. Trois ajouts modifient concrètement la façon d’écrire du code.
Pattern matching dans switch
Imaginez un bloc de code avec une cascade de instanceof suivis de casts manuels. En Java 17, cette écriture était courante. Java 21 rend le pattern matching dans le switch standard (il était en preview auparavant).
Vous pouvez désormais écrire un switch qui vérifie le type, extrait la valeur et applique une condition, le tout dans une seule expression. Le code devient plus court et plus lisible, sans sacrifier la sécurité de typage.
Record patterns et déconstruction
Les record patterns permettent de déconstruire un record directement dans un pattern. Au lieu d’appeler manuellement chaque accesseur, vous extrayez les composants en une ligne. Les record patterns suppriment le code d’extraction répétitif.
Virtual threads (projet Loom)
C’est probablement le changement le plus significatif pour les applications serveur. Les virtual threads sont des threads légers gérés par la JVM, pas par le système d’exploitation. Résultat : un serveur peut gérer bien plus de connexions concurrentes sans pool de threads complexe.
Si votre application traite beaucoup d’entrées-sorties (appels réseau, requêtes base de données), les virtual threads simplifient l’architecture. Les frameworks comme Spring Boot ou Quarkus les prennent déjà en charge.
Migration Java 17 vers 21 : le piège des dépendances
Beaucoup d’articles présentent la migration comme un simple changement de version dans le fichier de build. La réalité est plus nuancée.
Depuis Java 17, l’encapsulation forte des modules internes est activée par défaut. Certaines bibliothèques anciennes accèdent à des API internes de la JVM via la réflexion. En Java 21, ces accès non autorisés provoquent des InaccessibleObjectException si vous n’ajoutez pas d’options JVM spécifiques.
Les coupables habituels : des bibliothèques de mocking, des ORM qui manipulent le bytecode, des outils de sérialisation qui fouillent les champs privés. Le code Java de votre application compile probablement sans modification. Ce sont les dépendances tierces qui posent problème.
Avant de lancer une migration, un audit des dépendances est plus utile qu’un comparatif de fonctionnalités. Des outils comme OpenRewrite automatisent une partie du travail en appliquant des recettes de migration qui corrigent les incompatibilités connues.
Java 25 LTS : faut-il sauter Java 21 et migrer directement ?
Java 25 est désormais le LTS courant. Cela change la question de départ. Si vous êtes encore sur Java 17, vous avez maintenant deux chemins possibles : passer par Java 21, ou sauter directement vers Java 25.
Migrer directement de Java 17 à Java 25 est techniquement faisable, mais le saut est plus large. Chaque version intermédiaire a supprimé ou modifié des API. Plus l’écart entre versions est grand, plus le nombre de dépendances à mettre à jour augmente.
Java 21 reste un palier utile dans trois situations :
- Votre framework principal (Spring Boot 3.x, Quarkus) a été validé sur Java 21 mais pas encore certifié sur Java 25.
- Vous voulez adopter les virtual threads et le pattern matching sans gérer en même temps les breaking changes de Java 25.
- Votre distribution OpenJDK fournit un support long sur Java 21, ce qui vous laisse le temps de préparer la migration suivante.
Si votre stack est récente et que vos dépendances sont à jour, passer directement à Java 25 est l’option la plus économe en effort de migration à moyen terme.
Java 17 ou 21 : critères de choix concrets
Oubliez la question « quelle version est la meilleure ». La meilleure version Java est celle que votre écosystème supporte réellement.
Si vos dépendances sont toutes compatibles Java 21, que votre framework le supporte et que votre distribution JDK le maintient, Java 21 est le choix logique. Les virtual threads, le pattern matching standard et le ZGC générationnel (qui réduit les pauses de garbage collection sur les applications à gros tas mémoire) apportent des gains mesurables.
Si une bibliothèque critique n’a pas été mise à jour, ou si un serveur Minecraft impose Java 17 dans sa documentation, rester sur Java 17 n’est pas un retard technique. C’est une décision pragmatique.
Le vrai risque n’est pas de choisir la « mauvaise » version LTS. C’est de migrer sans avoir audité les dépendances, ou de payer une licence Oracle alors qu’une distribution gratuite couvre exactement le même périmètre fonctionnel.
