Quelle est la dernière version de Java ?

Tu as peut‑être déjà vécu ça : tu veux installer un logiciel, ou lancer un vieux projet, et là… message d’erreur mystérieux : « Java 8 requis », « Java 17 recommandé », ton collègue parle de Java 21, Google te parle de Java 22. Et toi tu te demandes :

« Bon, c’est laquelle, la vraie dernière version de Java, et laquelle je dois utiliser ? »

Je te rassure : tu n’es pas le seul à être perdu. Java a un rythme de sortie très régulier… et justement, c’est ce qui embrouille tout le monde.

On va démêler ça tranquillement, avec des repères simples et concrets.

Il y a deux réponses à « c’est quoi la dernière version de Java ? »

Je commence par la question qui fâche : quand quelqu’un demande « c’est quoi la dernière version de Java ? », en réalité il pose deux questions différentes :

• La toute dernière version sortie ? La plus récente, parfois expérimentale pour certains usages.
• La dernière version recommandée pour la majorité des projets ? Celle qu’on appelle une version LTS (support long terme).

Au moment où j’écris ces lignes :

• La dernière version LTS (celle qui compte pour la plupart des gens) est Java 21.
• Il existe aussi des versions intermédiaires plus récentes (par exemple Java 22), mais elles sont non‑LTS : très bien pour tester et profiter des nouveautés, moins pratique pour un projet qui doit vivre longtemps.

En gros :

• Tu veux de la stabilité → vise la dernière LTS (Java 21).
• Tu veux tester le futur ou faire du court terme → tu peux aller vers la dernière version non‑LTS.

On va voir ce que ça change vraiment pour toi.

Java a changé de rythme : une version tous les 6 mois

Avant, les nouvelles versions de Java arrivaient tous les x ans, avec de gros blocs de nouveautés (et beaucoup de suspense).

Aujourd’hui, le rythme est simple :

• Une nouvelle version tous les 6 mois.
• Une version LTS tous les quelques années (celles qu’on garde longtemps en prod).

Parmi les versions qui reviennent souvent dans les conversations :

• Java 8 : le dinosaure toujours vivant. Beaucoup d’anciens projets tournent encore dessus.
• Java 11 : LTS longtemps très populaire.
• Java 17 : LTS qui a remplacé 11 dans énormément de boîtes.
• Java 21 : la LTS actuelle. C’est un peu « le nouveau standard » qui s’installe.

Tu peux imaginer ça comme des stations de métro :

• Les versions non‑LTS sont les arrêts intermédiaires.
• Les versions LTS sont les grosses gares où beaucoup de monde monte et descend.

Si tu ne sais pas où aller, descends à la prochaine grande gare : Java 21.

Pourquoi tout le monde dit « prends la dernière LTS » ?

On pourrait se dire : « Autant prendre la toute dernière version, non ? »

Dans les faits, pour un projet sérieux qui doit vivre plusieurs années, la dernière LTS a trois gros avantages :

1. Support plus long
   Ça veut dire : mises à jour de sécurité, corrections de bugs pendant plusieurs années. Tu n’as pas à changer de version tous les quatre matins.

2. Écosystème prêt
   Les frameworks (Spring, Quarkus…), les serveurs, les bibliothèques ont le temps :

   • d’être testés,
   • de corriger les incompatibilités,
   • de documenter les bonnes pratiques.

3. Adoption massive
   Tu trouves :

   • beaucoup plus de tutos à jour,
   • des retours d’expérience,
   • des réponses sur Stack Overflow,
   • des collègues qui l’utilisent déjà.

Du coup, pour 95 % des usages « classiques », quand tu demandes « je mets quoi comme Java sur mon poste / serveur ? », la réponse qui revient, c’est :

« Prends la dernière LTS stable : aujourd’hui, Java 21. »

Comment savoir facilement quelle version utiliser dans TON cas

Je te propose un petit arbre de décision ultra simple.

1. Tu démarres un nouveau projet

• Tu n’as pas de contrainte particulière imposée par un vieux serveur ou une vieille lib ?
  → Pars sur Java 21.

• Tu veux absolument tester le tout dernier joujou du langage (une nouvelle preview, par exemple) et ton projet n’est pas critique ?
  → Tu peux tenter la toute dernière version non‑LTS… mais sache que tu devras probablement migrer dans les 6 à 12 mois.

2. Tu dois faire évoluer un projet existant

• Le projet est en Java 8 ou 11 :

  • Si tu peux, visez Java 17 ou 21, de préférence 21 pour voir loin.
  • Migrer directement 8 → 21, ça se fait, mais ça demande parfois un peu de tri dans les vieilles dépendances.

• Le projet tourne déjà en Java 17 :

  • Tu peux très bien rester dessus encore un moment si tout va bien.
  • Si tu prévois une grosse refonte ou une mise à jour d’infra, profites‑en pour viser Java 21.

• Le projet est bloqué parce qu’un logiciel tiers exige une version précise (un outil, un serveur d’appli, un vieux framework) :

  • Là, c’est lui qui donne le tempo.
  • Tu dois suivre ce qu’il supporte officiellement.

Comment savoir quelle version tu as déjà (et ce qui tourne où)

Dans le doute, je fais toujours la même chose :

• Sur ta machine :

  • Ouvre un terminal / invite de commande.
  • Tape : java -version
  • Tu verras un message du genre : openjdk version "21" ... ou "17", etc.

• Sur un serveur applicatif (Tomcat, WildFly, etc.) :

  • Souvent, les logs au démarrage indiquent la version de Java.
  • Tu peux aussi te connecter en SSH et faire le même java -version.

Astuce simple mais qui évite bien des migraines :

Note quelque part, projet par projet, « compile avec Java X, tourne avec Java Y ».

Parce que oui, on peut compiler avec une version et exécuter avec une autre, tant qu’on respecte certaines règles (target/bytecode, options du compilateur). Mais si tu veux une vie simple, garde les choses alignées.

Pourquoi ça vaut le coup de ne pas rester coincé sur une version vieille

Je croise encore beaucoup de projets en Java 8 « parce que ça marche bien comme ça ».

Je comprends la logique du « si ce n’est pas cassé, ne touche à rien ». Mais rester bloqué peut coûter cher sur plusieurs plans :

• Sécurité : moins de mises à jour, surface d’attaque plus grande si la version n’est plus suivie par ton fournisseur.
• Performance : les JVM modernes sont souvent plus rapides, plus économes en mémoire.
• Productivité des développeurs :
  • Nouvelles fonctionnalités du langage (pattern matching, records, switch amélioré, etc.).
  • Code plus lisible, plus court, moins d’erreurs bêtes.
• Écosystème : certains frameworks modernes abandonnent peu à peu le support des vieilles versions.

Tu n’es pas obligé de courir après chaque release tous les 6 mois, mais viser une LTS récente tous les quelques années, c’est un compromis très raisonnable.

Une façon concrète de planifier ta mise à jour Java

Je te propose une méthode simple, que j’utilise souvent pour aider à « dépoussiérer » des environnements :

1. Inventaire rapide
   Liste tous tes projets / applis avec :

   • version de Java utilisée,
   • frameworks principaux (Spring, Jakarta, etc.),
   • type d’hébergement (serveur maison, cloud, container…).

2. Spotter les cas simples

   • Projets récents, dépendances à jour → candidats parfaits pour passer à Java 21 rapidement.

3. Identifier les boulets techniques

   • Vieilles libs non maintenues,
   • serveurs d’appli archaïques,
   • outils qui exigent « Java 8 uniquement ».

   Pour ceux‑là, tu peux :

   • chercher une alternative maintenue,
   • isoler l’appli (par exemple dans un container avec son Java 8),
   • planifier une refonte plus tard.

4. Tester en environnement isolé

   • Fais tourner ton appli avec Java 21 sur un environnement de test.
   • Regarde les logs, les warnings, les dépréciations.
   • Lance ta batterie de tests (ou, au minimum, tes scénarios métier principaux).

5. Migrer progressivement, pas tout d’un coup

   • Priorise les projets les plus utilisés ou les plus exposés.
   • Apprends des premières migrations pour les suivantes.

Ce n’est pas très glamour, mais c’est ce qui fait la différence entre « on finira par passer un jour » et « on est à peu près à jour sans douleur ».

Et si je veux juste coder peinard sur mon PC ?

Si tu apprends Java, ou que tu codes surtout pour toi :

• Installe la dernière LTS (Java 21), tu auras :

  • un langage moderne,
  • des ressources à jour,
  • moins de problèmes de compatibilité.

• Si un tutoriel exige Java 17 ou autre, tu peux :

  • soit installer cette version en plus (on peut avoir plusieurs Java sur la même machine),
  • soit essayer avec Java 21 : souvent, ça marche très bien.

Les environnements de dev (IntelliJ, Eclipse, VS Code) savent généralement gérer plusieurs versions de JDK. Tu peux donc :

• garder une version « par défaut » (21),
• et configurer une version spécifique seulement pour les projets qui en ont besoin.

En résumé : ta boussole Java pour les prochaines années

Pour que tout soit clair sans devoir mémoriser un tableau :

• Question : « C’est quoi la dernière version de Java ? »
  → La plus récente techniquement change tous les 6 mois.
  → La dernière grande version recommandée (LTS) aujourd’hui : Java 21.

• Tu démarres un nouveau projet ?
  → Vise Java 21, sauf contrainte très spécifique.

• Tu es sur une vieille version (8/11) ?
  → Planifie un saut vers 17 ou 21, plutôt 21 si tu peux.

• Tu veux juste apprendre ou bricoler chez toi ?
  → Installe Java 21 et concentre‑toi sur le langage, pas sur les numéros.

Au fond, la vraie question n’est pas « quelle est la dernière version ? », mais plutôt :

« Quelle version est adaptée à ce que je veux faire, maintenant, sans me compliquer la vie dans deux ans ? »

Et là, Java 21 est aujourd’hui un très bon allié.

La bonne nouvelle, c’est que tu n’as pas besoin d’être à la poursuite permanente de la toute dernière release. Un choix réfléchi, tous les quelques années, ça suffit largement pour rester dans le train… sans finir accroché sur le marchepied.