Une version intermédiaire de Java peut-elle apporter de vraies améliorations sans bouleverser un projet existant ? Java 18 répond surtout à cette question avec une série d'évolutions ciblées, de l'encodage UTF-8 par défaut à un serveur web minimal, en passant par plusieurs fonctionnalités encore expérimentales. Je présente ici ce que cette édition a réellement changé, ses limites et la place qu'elle peut encore occuper en 2026.
Les repères essentiels avant de choisir cette version
- Java 18 est une version fonctionnelle publiée en mars 2022, mais elle n'est pas LTS.
- UTF-8 devient l'encodage par défaut, ce qui améliore la cohérence entre les environnements.
- jwebserver permet de lancer rapidement un serveur pour des fichiers statiques et des tests.
- Le filtrage par motifs dans switch, l'API Vector et l'API Foreign Function and Memory restent expérimentaux ou en incubation.
- Pour un nouveau projet en 2026, je privilégie une version LTS maintenue plutôt que cette édition intermédiaire.
Ce que représente réellement cette version de Java
Java 18 est une version du JDK, c'est-à-dire l'environnement utilisé pour compiler, exécuter et diagnostiquer des applications Java. Elle est sortie en mars 2022, dans le cycle de publication de six mois adopté par l'écosystème.
La différence entre une version standard et une version LTS, pour Long-Term Support, est importante. Une édition LTS reçoit un suivi plus long et convient mieux aux applications qui doivent rester stables pendant plusieurs années. Java 18 a surtout servi de terrain d'essai pour faire avancer des fonctionnalités vers les éditions suivantes.
Je le vois comme une version de transition intéressante pour les développeurs qui veulent tester les évolutions du langage et de la machine virtuelle. En revanche, je déconseille d'en faire aujourd'hui la base d'un nouveau produit exposé en production, sauf contrainte particulière de compatibilité.
Les nouveautés qui changent le quotidien
UTF-8 devient le choix par défaut
Le changement le plus discret est aussi l'un des plus utiles. Avec JEP 400, UTF-8 devient l'encodage par défaut pour les API Java qui dépendaient auparavant de la configuration du système d'exploitation.
Concrètement, une application qui lit des fichiers, traite des accents ou échange des données avec une API obtient un comportement plus prévisible entre Windows, Linux et macOS. Cela réduit les problèmes classiques de caractères remplacés par des symboles illisibles.
Il faut toutefois tester les anciennes applications. Si un programme supposait implicitement l'encodage local, le passage à UTF-8 peut modifier la lecture de fichiers historiques. Dans ce cas, je préfère indiquer explicitement l'encodage attendu plutôt que compter sur une valeur par défaut.
Un serveur web minimal pour les tests
Java 18 ajoute jwebserver, un outil en ligne de commande capable de servir un dossier contenant des fichiers statiques. Il s'agit d'un moyen rapide de tester une page HTML, un fichier JavaScript ou une documentation sans installer Apache, Nginx ou une application complète.
jwebserver -p 8000 -d publicCette commande expose le dossier public sur le port 8000. Je trouve l'outil particulièrement pratique pour vérifier une interface locale, partager temporairement des fichiers sur un réseau de développement ou reproduire un problème de chemin relatif.
Il ne faut pas lui demander davantage. Ce serveur n'est pas conçu pour la production et ne remplace pas un serveur web robuste avec gestion des accès, journalisation, certificats TLS et réglages de performance.
Une documentation Java plus facile à maintenir
La balise @snippet améliore la documentation produite avec JavaDoc. Elle permet d'intégrer des extraits de code de manière plus propre et de réduire les exemples copiés manuellement dans les commentaires.
Pour une bibliothèque publique, ce détail a un vrai intérêt. Un exemple documenté peut rester aligné avec le code source, ce qui limite les tutoriels internes qui compilent mal ou deviennent obsolètes après quelques modifications.
| Évolution | Utilité principale | Prudence à garder |
|---|---|---|
| UTF-8 par défaut | Éviter les différences d'encodage entre systèmes | Tester les fichiers hérités et les intégrations anciennes |
| jwebserver | Servir rapidement des fichiers statiques | Réservé au développement et aux essais |
@snippet |
Améliorer les exemples JavaDoc | Ne remplace pas une documentation fonctionnelle complète |
Les fonctionnalités expérimentales à manier avec méthode
La version apporte aussi des travaux plus ambitieux, mais tous ne sont pas prêts à devenir des fondations stables. C'est ici que beaucoup de présentations deviennent trop enthousiastes. Une fonctionnalité en preview peut encore changer et nécessite généralement une option spéciale pour compiler ou exécuter le programme.
Le filtrage par motifs dans switch
Le pattern matching for switch permet d'écrire une logique plus expressive lorsqu'un traitement dépend à la fois du type et de la valeur d'un objet. Au lieu de multiplier les conversions et les conditions, le code décrit directement les cas pris en charge.
static String décrire(Object valeur) {
return switch (valeur) {
case Integer nombre -> "Entier : " + nombre;
case String texte -> "Texte : " + texte;
case null -> "Valeur absente";
default -> "Autre type";
};
}L'exemple est lisible, mais cette fonction appartient encore à une étape de preview dans cette version. Pour l'essayer, il faut activer explicitement les fonctionnalités correspondantes avec --enable-preview. Je réserve donc ce mécanisme à un prototype, à une expérimentation ou à une branche de recherche, pas à une API publique qui doit rester stable.
Une meilleure base pour les calculs vectoriels
L'API Vector, proposée en incubation, cherche à exploiter les instructions vectorielles des processeurs pour traiter plusieurs valeurs en parallèle. Elle peut intéresser les calculs scientifiques, l'analyse d'images, certains algorithmes de chiffrement ou les traitements numériques intensifs.
Le gain dépend fortement du matériel, de l'algorithme et de la qualité du profilage. Je ne remplacerais pas une boucle classique par une API vectorielle simplement parce qu'elle semble plus moderne. Il faut mesurer le résultat avec des benchmarks représentatifs, car la complexité supplémentaire n'apporte pas toujours un bénéfice visible.
Des appels natifs plus modernes
L'API Foreign Function and Memory vise à permettre à Java d'interagir avec de la mémoire externe et des fonctions natives sans dépendre systématiquement de JNI. Elle ouvre des perspectives pour les bibliothèques système et les intégrations avec du code C ou C++.
Cette approche peut réduire une partie de la plomberie technique, mais elle touche à des zones sensibles comme la gestion de la mémoire et la sécurité. Dans un produit réel, je vérifierais d'abord la maturité de la bibliothèque utilisée et la compatibilité avec la version LTS retenue.
La finalisation est officiellement sur la sellette
Java 18 déprécie la finalisation en vue de sa suppression future. Cette technique permettait de déclencher automatiquement du nettoyage lorsqu'un objet était récupéré, mais son comportement est difficile à prévoir et peut retarder la libération de ressources.
Pour les fichiers, les sockets et les connexions, je recommande depuis longtemps try-with-resources. Cette construction rend la fermeture explicite et fiable, ce qui est beaucoup plus important qu'un mécanisme automatique dépendant du ramasse-miettes.
Faut-il encore utiliser Java 18 en 2026
Pour apprendre les évolutions historiques de Java ou maintenir une application qui dépend précisément de cette version, oui. Pour démarrer un projet aujourd'hui, mon choix serait différent, car Java 18 n'est pas une version LTS et son cycle de maintenance est terminé depuis plusieurs années.
Je regarderais plutôt Java 17, Java 21 ou Java 25 selon les contraintes de l'équipe, des frameworks et de l'infrastructure. Une version LTS facilite les mises à jour de sécurité, la compatibilité avec les outils de build et le support proposé par les éditeurs.
| Situation | Choix raisonnable | Pourquoi |
|---|---|---|
| Découvrir les nouveautés apparues autour de 2022 | Java 18 | Environnement adapté à l'apprentissage et aux essais |
| Maintenir une application existante | Version actuelle du projet | Éviter une migration inutile et vérifier d'abord les dépendances |
| Créer un service destiné à durer | Une version LTS maintenue | Meilleur suivi, moins de migrations rapprochées |
| Exploiter une fonctionnalité preview | Version recommandée par le framework | Réduire le risque de changement d'API ou de comportement |
Le piège le plus courant consiste à confondre nouveauté et intérêt opérationnel. Les fonctionnalités expérimentales sont utiles pour préparer l'avenir, mais elles ne justifient pas à elles seules une migration complète d'un système stable.
Tester ou migrer sans casser l'existant
Avant toute migration, je commence par identifier la version réellement utilisée par le compilateur, le serveur d'application et les outils de déploiement. La commande suivante permet de vérifier le runtime actif :
java -versionJe contrôle ensuite la version du compilateur, les options du système de build et les dépendances qui utilisent des API internes. Une application peut sembler compatible parce qu'elle démarre, tout en produisant des différences de comportement au niveau de l'encodage, des certificats ou de la réflexion.
Lire aussi : Or en Java - Évitez les bugs et l'overflow en modélisant bien
Une méthode de validation simple
- Compiler avec la nouvelle version sans activer les fonctionnalités preview.
- Exécuter les tests automatisés, notamment ceux qui lisent des fichiers ou communiquent avec des services externes.
- Vérifier les journaux afin de repérer les avertissements de dépréciation.
- Comparer les performances sur des scénarios réels plutôt que sur un seul microbenchmark.
- Tester le déploiement dans un environnement proche de la production.
Pour une application ancienne, je porterais une attention particulière aux fichiers CSV, aux imports XML, aux flux réseau et aux bibliothèques qui supposent un encodage local. Le changement vers UTF-8 est bénéfique, mais il peut révéler des données déjà mal enregistrées.
Si une fonctionnalité preview est indispensable, je l'isole derrière une interface simple. Ainsi, le reste du code ne dépend pas directement d'une API susceptible d'évoluer, et un remplacement ultérieur reste possible sans réécrire toute l'application.
Le bon réflexe pour un projet Java actuel
Java 18 reste une étape intéressante dans l'évolution du langage. Elle a rendu l'encodage plus cohérent, ajouté un petit serveur web utile au quotidien et préparé des avancées qui ont gagné en maturité dans les versions suivantes.
Mon conseil est donc nuancé. Utilisez cette édition pour comprendre son apport, reproduire un comportement historique ou tester une idée, mais choisissez une version LTS encore maintenue pour un nouveau service, une application métier ou une infrastructure qui doit rester fiable plusieurs années.
La meilleure migration n'est pas celle qui adopte le numéro le plus récent. C'est celle qui apporte un bénéfice mesurable, conserve la compatibilité avec l'écosystème et laisse à l'équipe assez de temps pour maintenir le code correctement.
