Découvrez quelques-unes des nouveautés de Java 25 LTS, avec un focus sur les Scoped Values et les Virtual Threads qui révolutionnent la gestion de la concurrence.
Java 25 LTS marque un tournant majeur pour la plateforme. Cette nouvelle version apporte des fonctionnalités attendues, notamment en matière de gestion de la concurrence. L’introduction des Virtual Threads (en preview dès la version 19, finalisés à la version 21) et la finalisation des Scoped Values (en preview à la version 21, finalisés à la 25) visent à simplifier le code, à améliorer les performances et à permettre une meilleure scalabilité. Cet article vous guidera à travers ces innovations et expliquera leurs avantages par rapport aux approches existantes comme Spring Reactor et RxJava.
Pour une documentation technique plus détaillée sur les Virtual Threads, vous pouvez consulter la JEP 444 (https://openjdk.org/jeps/444).
En tant qu’ESN, Webnet accompagne les organisations dans la conception et l’évolution de leurs solutions numériques.
Comprendre ces fonctionnalités de Java 25 LTS
Java 25 est une version Long-Term Support (LTS) sortie en septembre 2025, ce qui signifie qu’elle bénéficiera d’un support prolongé de la part d’Oracle. Cela la rend idéale pour les projets d’entreprise qui nécessitent une stabilité sur le long terme. Les deux innovations majeures de cette version sont les Virtual Threads, qui simplifient la programmation concurrente, et les Scoped Values, une alternative plus sécurisée pour le partage de données.
Virtual Threads : la fin de la complexité asynchrone ?
Qu’est-ce qu’un Virtual Thread ?
Les Virtual Threads (https://openjdk.org/projects/loom/) font partie du Projet Loom, une initiative d’Open JDK visant à repenser la concurrence sur la JVM. Ils représentent une nouvelle approche pour la gestion de la concurrence, en proposant un modèle de threads légers, gérés par la JVM elle-même, et non par le système d’exploitation. Un Virtual Thread est conçu pour être très peu coûteux à créer et à gérer. Des millions de Virtual Threads peuvent coexister sur un seul thread du système d’exploitation (appelé carrier thread), ce qui permet à la JVM d’optimiser l’utilisation des ressources et de supporter un nombre de requêtes simultanées beaucoup plus important sans les problèmes de performances associés aux threads traditionnels.
Cette architecture permet aux développeurs d’écrire du code impératif et bloquant comme ils en ont l’habitude, tout en profitant des avantages d’une exécution non-bloquante sous le capot. Lorsqu’un Virtual Thread effectue une opération d’E/S (lecture d’une base de données, appel à un service web), la JVM le met en pause et libère le carrier thread pour qu’il puisse exécuter une autre tâche. Il n’y a plus de callbacks ni de chaînes d’appels complexes à gérer.
Cette avancée s’inscrit pleinement dans notre expertise en développement Java et notre maîtrise des architectures performantes.
Comparaison avec les autres langages
Le concept de Virtual thread s’inscrit dans une tendance observée dans d’autres langages modernes. Par exemple, ils partagent une philosophie similaire au coroutines de Kotlin, qui permettent d’écrire du code concurrent de manière impérative et non bloquante sous le capot. Java propose ainsi une solution native pour la JVM, tirant parti de son architecture existante.
Exemple de code : simplicité retrouvée
L’exemple suivant montre comment le code impératif redevient la norme pour la concurrence, sans les CompletableFuture :
Scoped Values : une alternative plus sûre aux ThreadLocals
À quoi servent les Scoped Values ?
Le concept de Scoped Values a été finalisé dans le cadre de la JEP 464 (https://openjdk.org/jeps/464).
Les Scoped Values sont conçus pour le partage de données immuables au sein d’une méthode ou entre plusieurs appels de méthodes sans avoir à les passer explicitement en tant que paramètres. Cela simplifie la signature des méthodes, rend le code plus propre et améliore la maintenabilité.
Cette amélioration est due au fait que, contrairement aux ThreadLocal qui peuvent causer des fuites de mémoire et des problèmes de concurrence, les Scoped Values garantissent que la valeur est disponible uniquement dans le contexte d’exécution d’un Virtual Thread et sont immuables, ce qui rend le flux de données plus prévisible.
Exemple de code : propagation et sécurité
Le code suivant montre comment une valeur est définie pour une portée et est automatiquement propagée, même aux threads enfants :
Performances et Scalabilité: les chiffres
L’un des arguments les plus forts de Java 25 est l’amélioration de la scalabilité pour les tâches liées aux E/S. Un test de performance mené sur une application Spring Boot 3.2, simulant 10 000 requêtes concurrentes avec une latence de 100 ms (simulant une requête de base de données), démontre un gain significatif (Spring Boot Performance with Java Virtual Threads – Java Code Geeks):
| Métrique | Platform Threads (200 max) | Virtual Threads |
| Requêtes Complétées | 10 000 | 10 000 |
| Mémoire maximale utilisée | 2,1 Go | 1,2 Go |
| Temps de Réponse Moyen | 320 ms | 110 ms |
| 99e Centile (Latence de queue) | 890 ms | 210 ms |
Conclusion du Benchmark : Les Virtual Threads ont réduit la consommation de mémoire de 43% et ont amélioré la latence de queue (99e centile) par un facteur de 4.
Virtual Threads et Scoped Values vs. Spring Reactor et RxJava
Points communs et différences
L’objectif de Java 25 LTS est d’offrir une solution intégrée pour le développement d’applications hautement concurrentielles, tout comme les frameworks réactifs tels que Spring Reactor ou RxJava. Cependant, l’approche est fondamentalement différente.
- Spring Reactor et RxJava s’appuient sur un modèle de programmation réactif et non-bloquant. Le développeur utilise des Mono ou des Flux (des flux de données) et des opérateurs pour chaîner les opérations de manière asynchrone. Cette approche est très efficace pour gérer la backpressure (adaptation du débit) et les flux de données continus, mais elle nécessite une courbe d’apprentissage plus raide et un style de code très différent du code impératif classique.
- Les Virtual Threads reviennent à un modèle impératif et bloquant. Le code est plus facile à lire, à écrire et à débugger. La gestion des exceptions et le flux d’exécution sont linéaires, ce qui réduit considérablement la complexité.
Quand choisir, quelle approche ?
Le choix entre les deux dépend des besoins de votre application.
- Choisissez Java 25 LTS et ses Virtual Threads si vous développez des applications back-end classiques, des microservices et des API qui effectuent principalement des opérations d’E/S bloquantes. C’est aussi un excellent choix pour migrer du code existant sans une réécriture complète vers le modèle réactif. L’approche est plus simple et plus intuitive pour la majorité des développeurs.
- Choisissez un framework réactif comme Spring Reactor si vous traitez des flux de données continus, si vous avez besoin d’une gestion fine de la backpressure ou si vous travaillez déjà dans un écosystème réactif.
Conclusion
En résumé, Java 25 ne rend pas les frameworks réactifs obsolètes, mais il propose une alternative plus simple et plus adaptée à de nombreux cas d’usage. Les Virtual Threads et les Scoped Values permettent aux développeurs d’écrire du code concurrent de manière plus lisible et plus maintenable, tout en bénéficiant de la scalabilité et des performances nécessaires aux applications modernes.
Pour échanger sur vos besoins ou vos projets, vous pouvez contacter Webnet.
Cette version pourrait bien marquer le début d’une nouvelle ère pour la programmation Java.
