Maintenant que Java 19 est features complete (Rampdown Phase One au jour d\u2019\u00e9criture de l\u2019article), c\u2019est le moment de faire le tour des fonctionnalit\u00e9s qu\u2019apporte cette nouvelle version, \u00e0 nous, les d\u00e9veloppeurs.<\/p>\n
Cet article fait partie d\u2019une suite d\u2019article sur les nouveaut\u00e9s des derni\u00e8res versions de Java<\/a>, pour ceux qui voudraient les lire en voici les liens : Java 18<\/a>, Java 17<\/a>, Java 16<\/a>, Java 15<\/a>, Java 14<\/a>, Java 13<\/a>, Java 12<\/a>, Java 11<\/a>,\u00a0Java 10,<\/a>\u00a0et\u00a0Java 9<\/a>.<\/p>\n Cette JEP vise \u00e0 enrichir le pattern matching de Java avec les record patterns qui permettent de d\u00e9construire un record en ses attributs.<\/p>\n Un record est un nouveau type dont le but est d’\u00eatre un conteneur de donn\u00e9e, il a \u00e9t\u00e9 introduit en Java 14<\/a>.<\/p>\n Avant la JEP 405, si vous vouliez faire du pattern matching sur un record puis acc\u00e9der \u00e0 ses attributs, vous auriez \u00e9crit du code comme celui-ci :<\/p>\n La JEP 405 permet de d\u00e9construire le record et de directement acc\u00e9der \u00e0 ses attributs quand le pattern match, ce qui simplifie le code comme suit :<\/p>\n Au lieu, dans le bloc de code ex\u00e9cut\u00e9 au match du pattern, d’avoir acc\u00e8s \u00e0 la variable C’est la premi\u00e8re \u00e9tape dans la d\u00e9construction de type en Java, on peut esp\u00e9rer voir prochainement la d\u00e9construction arriver pour toutes les classes et pas uniquement les records.<\/p>\n Plus d’information dans la JEP 405<\/a>.<\/p>\n RISC-V est une architecture de jeu d’instructions (Instruction Set Architecture – ISA) RISC (Reduced Instruction Set Computer) gratuite et open source con\u00e7ue \u00e0 l’origine \u00e0 l’Universit\u00e9 de Californie \u00e0 Berkeley, et maintenant d\u00e9velopp\u00e9e en collaboration sous le parrainage de RISC-V International : https:\/\/riscv.org<\/a><\/a>.<\/p>\n RISC-V d\u00e9finit plusieurs ISA, seul le jeu d’instruction RV64GV (general purpose 64bit) a \u00e9t\u00e9 port\u00e9.<\/p>\n Ce port comprend le support du JIT (C1 et C2) ainsi que de tous les GC existant (y compris ZGZ et Shenandoah).<\/p>\n Plus d’information dans la JEP 422<\/a>.<\/p>\n La JEP 425 introduit en preview feature les Virtual Threads (parfois aussi nomm\u00e9s green threads ou lightweight threads), ce sont des threads l\u00e9gers, avec un co\u00fbt de cr\u00e9ation et de scheduling faible, qui permettent de faciliter l’\u00e9criture d’application concurrente.<\/p>\n C’est le projet Loom <\/strong> d’OpenJDK.<\/p>\n Les threads Java classiques sont impl\u00e9ment\u00e9s via des threads OS, quel est le probl\u00e8me avec cette impl\u00e9mentation de thread ?<\/p>\n Pour palier \u00e0 ces probl\u00e8mes, les applications concurrentes ont eu recours \u00e0 plusieurs types de construction :<\/p>\n Mais ces constructions impliquent de la complexit\u00e9 lors du d\u00e9veloppement des applications. L’id\u00e9e des Virtual Threads est d’offrir des threads peu couteux \u00e0 cr\u00e9er, et donc de permettre de se passer de pool de threads ou d’event loop et d’utiliser un thread pour chaque requ\u00eate. C’est la promesse du projet Loom.<\/p>\n Le principe est de proposer des threads virtuels qui sont cr\u00e9\u00e9s et schedul\u00e9s par la JVM, et utilisent un pool de thread OS, ce que l’on appelle des carrier threads (thread porteur). La JVM va alors automatiquement monter et d\u00e9monter les threads virtuels des carrier threads quand n\u00e9cessaire (lors des I\/O par exemple). Les stacks des threads seront stock\u00e9es dans la heap de la JVM, leur taille n’\u00e9tant plus fixe, un gain en m\u00e9moire est possible.<\/p>\n La mani\u00e8re la plus simple de cr\u00e9er des threads virtuels est via L\u00e0 o\u00f9 les threads virtuels sont le plus int\u00e9ressant est pour les applications qui n\u00e9cessitent une grande concurrence (plusieurs dizaines de milliers de thread) et\/ou qui ne sont pas CPU bound (g\u00e9n\u00e9ralement celles ex\u00e9cutant des I\/O). Attention, utiliser des threads virtuels pour des applications CPU bound, des applications faisant des calculs intense par exemple, est contre-productif, car avoir plus de threads que de CPU pour ce type d’application impact n\u00e9gativement les performances.<\/p>\n Il existe des limitations dans l’impl\u00e9mentation actuelle des threads virtuels, dans certains cas un thread virtuel va \u00e9pingler (pinning) le carrier thread qui ne pourra pas traiter d’autres threads virtuels :<\/p>\n \u00c0 cause de ces limitations, les threads virtuels ne sont pas forc\u00e9ment la solution \u00e0 tous les probl\u00e8mes de concurrence, m\u00eame si des am\u00e9liorations pourrons \u00eatre faites dans les prochaines version de Java. Il faudra aussi que l’\u00e9cosyst\u00e8me devienne compatible avec les threads virtuels (par exemple en \u00e9vitant l’utilisation de bloc synchronis\u00e9).<\/p>\n Plus d’information dans la JEP 425<\/a>.<\/p>\n Incubator module qui offre une nouvelle API permettant de simplifier l’\u00e9criture de code multi-thread\u00e9 en permettant de traiter plusieurs t\u00e2ches concurrentes comme une unit\u00e9 de traitement unique.<\/p>\n M\u00eame si les Virtual Threads sont les stars de cette nouvelle version de Java, l’API Structured Concurrency est pour moi aussi int\u00e9ressante, si ce n’est plus, en tout cas pour un d\u00e9veloppeur, car va impacter fortement la mani\u00e8re d’\u00e9crire du code multi-thread\u00e9 \/ concurrent.<\/p>\n Le but de cette API est de pouvoir \u00e9crire un code multi-thread\u00e9 plus lisible et avec moins de risque d’erreur dans son impl\u00e9mentation via une meilleure gestion des erreurs.<\/p>\n Avant la Structured Concurrency API, pour ex\u00e9cuter un ensemble de t\u00e2ches concurrentes, puis joindre les r\u00e9sultats ; on \u00e9crivait un code comme celui-ci (exemple pris de la JEP).<\/p>\n Il y a plusieurs probl\u00e8mes ici :<\/p>\n Avec la Structured Concurrency API, on peut utiliser la classe Ici les deux sous-t\u00e2ches Plus d’information dans la JEP 428<\/a>.<\/p>\n Les fonctionnalit\u00e9s suivantes restent en preview (ou en incubator module).<\/p>\n Pour les d\u00e9tails sur celles-ci, vous pouvez vous r\u00e9f\u00e9rer \u00e0 mes articles pr\u00e9c\u00e9dents.<\/p>\n Divers ajouts au JDK :<\/p>\n La totalit\u00e9 des nouvelles API du JDK 19 peuvent \u00eatre trouv\u00e9es dans The Java Version Almanac – New APIs in Java 19<\/a>.<\/p>\n Chaque nouvelle version du JDK apporte ses optimisations de performances (entre autres GC et m\u00e9thodes intrisics), et de s\u00e9curit\u00e9. Celle-ci ne fait pas d\u00e9faut.<\/p>\n C\u00f4t\u00e9 s\u00e9curit\u00e9, le focus a \u00e9t\u00e9 mis sur le renforcement de la s\u00e9curit\u00e9 de la JVM et les performance du TLS. Vous pouvez vous r\u00e9f\u00e9rer \u00e0 l’article de Sean Mullan pour une liste exhaustive des changements de s\u00e9curit\u00e9 inclus cette version : JDK 19 Security Enhancements<\/a><\/p>\nJEP 405 : Record Patterns (Preview)<\/h2>\n
\nrecord Point(int x, int y) {}\n\nstatic void printSum(Object o) {\n if (o instanceof Point p) {\n int x = p.x();\n int y = p.y();\n System.out.println(x + y);\n }\n}\n<\/pre>\n\nrecord Point(int x, int y) {}\n\nvoid printSum(Object o) {\n if (o instanceof Point(int x, int y)) {\n System.out.println(x + y);\n }\n}\n<\/pre>\nPoint p<\/code>; vous avez acc\u00e8s directement aux attribut int x, int y<\/code> du record Point<\/code>.<\/p>\nJEP 422 : Linux\/RISC-V Port<\/h2>\n
JEP 425 : Virtual Threads (Preview)<\/h2>\n
Virtual threads are lightweight threads that dramatically reduce the effort of writing, maintaining, and observing high-throughput concurrent applications.<\/blockquote>\n
-Xss<\/code> ou -XX:ThreadStackSize<\/code>.<\/li>\n\nExecutors.newVirtualThreadPerTaskExecutor()<\/code>, on a alors un ExecutorService<\/code> qui ex\u00e9cutera chaque t\u00e2che dans un nouveau thread virtuel.<\/p>\nsynchronized<\/code><\/li>\n\nnative<\/code> ou de l’API Foreign Function de la JEP 424<\/a><\/li>\n<\/ul>\nJEP 428 : Structured Concurrency (Incubator)<\/h2>\n
Simplify multithreaded programming by introducing a library for structured concurrency. Structured concurrency treats multiple tasks running in different threads as a single unit of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability.<\/blockquote>\n
\nExecutorService ex = Executors.newFixedThreadPool(nbCores);\nResponse handle() throws ExecutionException, InterruptedException {\n Future user = es.submit(() -> findUser());\n Future order = es.submit(() -> fetchOrder());\n String theUser = user.get(); \/\/ Join findUser \n int theOrder = order.get(); \/\/ Join fetchOrder\n return new Response(theUser, theOrder);\n}\n<\/pre>\nfetchOrder()<\/code>, on va quand m\u00eame attendre la fin de la t\u00e2che findUser()<\/code><\/li>\n\nfindUser()<\/code>, alors la m\u00e9thode handle()<\/code> va se terminer, mais le thread qui ex\u00e9cute fetchOrder()<\/code> va continuer \u00e0 s’ex\u00e9cuter, c’est un thread leak.<\/li>\n\nhandle()<\/code> est interrompue, cette interruption n’est pas propag\u00e9e aux sous-t\u00e2ches et leurs threads vont continuer \u00e0 s’ex\u00e9cuter, c’est un thread leak.<\/li>\n<\/ul>\nStructuredTaskScope<\/code> qui permet de lancer un ensemble de t\u00e2ches et de les g\u00e9rer comme une unit\u00e9 de traitement unique. Le principe est de d\u00e9couper une t\u00e2che en sous t\u00e2che (via fork()<\/code>) qui vont se terminer au m\u00eame endroit : scope.join()<\/code>. Voici l’exemple pris de la JEP.<\/p>\n\nResponse handle() throws ExecutionException, InterruptedException {\n try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {\n Future user = scope.fork(() -> findUser()); \n Future order = scope.fork(() -> fetchOrder());\n\n scope.join(); \/\/ Join both forks\n scope.throwIfFailed(); \/\/ ... and propagate errors\n\n \/\/ Here, both forks have succeeded, so compose their results\n return new Response(user.resultNow(), order.resultNow());\n }\n}\n<\/pre>\nfindUser()<\/code> et fetchOrder()<\/code> sont d\u00e9marr\u00e9s dans leur propre thread (par d\u00e9faut un thread virtuel), mais sont jointes et potentiellement annul\u00e9es ensemble (comme une une unit\u00e9 de traitement). Leurs exceptions et leurs r\u00e9sultats seront agr\u00e9g\u00e9s dans la t\u00e2che parente, et toute interruption du thread parent sera propag\u00e9 aux threads enfants. Lors d’un thread dump, on verra bien les sous-t\u00e2ches comme enfants du thread parent, facilitant le debugging de code \u00e9crit de cette mani\u00e8re.<\/p>\nLes fonctionnalit\u00e9s qui restent en preview<\/h2>\n
MemorySegments<\/code>.<\/li>\n\nwhen<\/code> pour les guards \u00e0 la place du &&<\/code>.<\/li>\n<\/ul>\nDivers<\/h2>\n
BigInteger.parallelMultiply()<\/code> : identique \u00e0 BigInteger.parallelMultiply()<\/code> mais va utiliser un algorithme parall\u00e8le qui utilisera plus de ressources CPU et m\u00e9moire pour les grands nombres.<\/li>\n\nInteger<\/code> et Long<\/code> voient l’ajout des m\u00e9thodes compress<\/code> et expand<\/code><\/li>\n\nHashMap.newHashMap(int)<\/code>, HashSet.newHashSet(int)<\/code>, LinkedHashMap.newLinkedHashMap(int)<\/code> et LinkedHashSet.newLinkedHashSet(int)<\/code> : ces m\u00e9thodes permettent de cr\u00e9er des maps ou des sets pouvant accueillir le nombre d’\u00e9l\u00e9ments pass\u00e9 en param\u00e8tre sans d\u00e9clencher de resize.<\/li>\n\nLocale<\/code> ont \u00e9t\u00e9 d\u00e9pr\u00e9ci\u00e9s, il faut maintenant construire une locale via Locale.of()<\/code>.<\/li>\n<\/ul>\nDes changements internes, de la performance, et de la s\u00e9curit\u00e9<\/h2>\n