Maintenant que Java 24 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 23<\/a>, Java 22<\/a>, Java 21<\/a>, Java 20<\/a>, Java 19<\/a>, 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 Java 24 contient par moins de 24 JEP, c’est un record et surtout un chiffre \u00e9ponyme !<\/p>\n Shenandoah est un Garbage Collector (GC) initialement d\u00e9velopp\u00e9 par RedHat et inclus dans OpenJDK. Il r\u00e9duit les temps de pause du GC en effectuant le travail d’\u00e9vacuation en m\u00eame temps que les threads applicatifs en cours d’ex\u00e9cution.<\/p>\n Jusqu’ici, Shenandoah n’\u00e9tait pas g\u00e9n\u00e9rationnel, ce qui veut dire qu’il ne s\u00e9parait pas la heap en plusieurs zones contenant des objets d’age diff\u00e9rent. Les GC g\u00e9n\u00e9rationnels se basent sur la Weak Generational Hypotesis<\/strong> : most objects die young<\/em>, comme collecter un objet mort est tr\u00e8s peu co\u00fbteux, s\u00e9parer les objets jeunes des objets vieux permet de se focaliser sur les objets jeunes pour nettoyer la heap de mani\u00e8re plus performante.<\/p>\n Tous les GC actuels sont g\u00e9n\u00e9rationnels, m\u00eame ZGC qui ne l’\u00e9tait pas \u00e0 ses d\u00e9buts, mais qui depuis cette release ne supporte plus que le mode g\u00e9n\u00e9rationnel. Shenandoah en ajoutant un mode g\u00e9n\u00e9rationnel en exp\u00e9rimental comble son retard.<\/p>\n Shenandoah est un GC concurrent, cela a un co\u00fbt en termes d’utilisation de ressources CPU et m\u00e9moire, un mode g\u00e9n\u00e9rationnel devrait permettre de mitiger le co\u00fbt de fonctionnement du GC tout en gardant un objectif de pause de l’ordre de la milliseconde.<\/p>\n Pour activer le mode g\u00e9n\u00e9rationnel, il faut utiliser les options JVM suivantes : Plus d’information dans la JEP 404<\/a>.<\/p>\n Cette JEP provient du projet Liliput dont le but est de r\u00e9duire la taille du header des objets de 128 bits \u00e0 64 bits ou moins. C’est d\u2019ailleurs tr\u00e8s exactement ce qu’a d\u00e9livr\u00e9 la JEP 450 : un mode exp\u00e9rimental pour la JVM qui r\u00e9duit \u00e0 64 bits le header des objets.<\/p>\n Chaque objet en Java a un header, puis de la donn\u00e9es<\/em> : ses attributs. Si vous avez un objet Les premiers 64 bits d’un header sont nomm\u00e9s Mark Word<\/em> et stockent soit le hash code, l’\u00e2ge GC et certains flags n\u00e9cessaire pour la JVM; soit un pointeur vers une structure externe. Les derniers 64 bits sont nomm\u00e9s Class Word<\/em> et stockent un pointeur vers la classe. Le mode sp\u00e9cial Compressed Class Pointer<\/em> permet d\u00e9j\u00e0 de le r\u00e9duire \u00e0 32 bits, mais sur une architecture 64 bits, l’alignement en m\u00e9moire fait que le gain n’est pas forc\u00e9ment pr\u00e9sent m\u00eame si la JVM peut optimiser le layout d’un objet en utilisant ces 32 bits ainsi lib\u00e9r\u00e9s.<\/p>\n En activant les headers d’objets compacts via les options JVM Des tests pr\u00e9liminaires montrent une utilisation m\u00e9moire r\u00e9duite de 10 \u00e0 20 %.<\/p>\n Amazon a r\u00e9alis\u00e9 des tests qui montrent que de nombreuses charges de travail b\u00e9n\u00e9ficient d’une baisse de l’utilisation CPU pouvant aller jusqu’\u00e0 30 %.<\/p>\n Il y a quelques limites \u00e0 ce mode, il ne peut supporter les heap de plus de 8TB (sauf pour ZGC) et se limite \u00e0 4 millions de classes.<\/p>\n Plus d’information dans la JEP 450<\/a>.<\/p>\n La JEP 472 restreint l’utilisation la Java Native Interface (JNI) et ajuste l’API Foreign Function and Memory (FFM) en cons\u00e9quence.<\/p>\n L’utilisation d’une fonction native g\u00e9n\u00e9rera un WARNING au d\u00e9marrage de la JVM sauf si l’option JVM L’utilisation d’une fonction native sans l’avoir autoris\u00e9e au pr\u00e9alable est dite ill\u00e9gale, l’option JVM Exemple de warning g\u00e9n\u00e9ra par la JVM au chargement d’une librairie native si l’acc\u00e8s n’a pas \u00e9t\u00e9 autoris\u00e9 :<\/p>\n Le comportement par d\u00e9faut de la JVM en cas d’utilisation d’une librairie native passera de Cette JEP fais partie d’une ensemble de changement dans la JVM pour restreinte certaines fonctionnalit\u00e9s de la JVM par d\u00e9faut, en for\u00e7ant l’utilisateur \u00e0 activer sp\u00e9cifiquement ces fonctionnalit\u00e9s, dans le but d’avoir une JVM plus robuste. Vous pouvez en lire plus sur le sujet dans la JEP en draft Integrity by Default<\/a>.<\/p>\n Plus d’information dans la JEP 472<\/a>.<\/p>\n La JEP 475 simplifie la mise en place des barri\u00e8res du Garbage Collector (GC) G1 en d\u00e9pla\u00e7ant leur expansion du d\u00e9but du pipeline de compilation du Just In Time (JIT) compiler de la JVM (C2) vers la fin.<\/p>\n G1 utilise des barri\u00e8res pour enregistrer des informations sur les acc\u00e8s \u00e0 la m\u00e9moire de l’application. Ces barri\u00e8res n\u00e9cessitent une interaction avec le JIT et en complexifient le code et la maintenance.<\/p>\n Des tests pr\u00e9liminaire ont montr\u00e9 que la mise en place des barri\u00e8res G1 avait un overhead de 10 \u00e0 20% sur le JIT<\/a>. L’id\u00e9e est qu’au lieu d’injecter la barri\u00e8re au d\u00e9but de la phase de compilation (dans l’IR – l’intermediate representation du code \u00e0 compiler) et de laisser C2 compiler le code de la barri\u00e8re, il est plus int\u00e9ressant de l’injecter \u00e0 la fin de la phase de compilation directement en assembleur.<\/p>\n Plus d’information dans la JEP 475<\/a> ainsi que dans l’article When should a compiler expand garbage collection barriers?<\/a> de Roberto Casta\u00f1eda Lozano.<\/p>\n Nouvelle API pour les fonctions de d\u00e9rivation de cl\u00e9s (Key Derivation Function – KDF), qui sont des algorithmes cryptographiques permettant de d\u00e9river des cl\u00e9s suppl\u00e9mentaires \u00e0 partir d’une cl\u00e9 secr\u00e8te et d’autres donn\u00e9es.<\/p>\n KDF fait partie du standard de cryptographie PKCS #11<\/a>.<\/p>\n KDF est aussi une des briques n\u00e9cessaires pour l’impl\u00e9mentation de l’Hybrid Public Key Encryption (HPKE) qui est un algorithme de cryptographie post-quantique. La cryptographie post-quantique regroupe un ensemble d’algorithme cryptographique qui sont r\u00e9sistants aux ordinateurs quantiques. Je reviendrai sur le sujet dans la section traitant des algorithmes de type Module-Lattice-Based<\/strong> via les JEP 496 et 497.<\/p>\n Plus d’information dans la JEP 478<\/a>.<\/p>\n Le port de la JVM pour Windows 32-bit pour les architectures x86 a \u00e9t\u00e9 d\u00e9pr\u00e9ci\u00e9 en Java 21, il sera supprim\u00e9 en Java 24.<\/p>\n Plus d’information dans la JEP 479<\/a>.<\/p>\n Le but de cette nouvelle fonctionnalit\u00e9 est d’am\u00e9liorer le temps de d\u00e9marrage de la JVM en rendant les classes d’une application instantan\u00e9ment disponibles, dans un \u00e9tat charg\u00e9 et li\u00e9, lorsque la JVM d\u00e9marre.<\/p>\n Pour cela, un premier lancement de l’application est n\u00e9cessaire. Lors de ce lancement, les classes charg\u00e9es sont enregistr\u00e9es dans un cache pour \u00eatre disponibles imm\u00e9diatement lors de lancements successifs.<\/p>\n Dans la JVM, les classes sont charg\u00e9es \u00e0 la demande via un ClassLoader. La JVM est dynamique, la liste des classes \u00e0 charger n’est pas fixe au d\u00e9marrage, car des classes peuvent \u00eatre cr\u00e9\u00e9es dynamiquement (par exemple : via des proxies dynamiques), ou charg\u00e9es dynamiquement via r\u00e9flexion.<\/p>\n Mais charger une classe \u00e0 un co\u00fbt :<\/p>\n M\u00eame si ces \u00e9tapes sont optimis\u00e9es, une application qui utilise des centaines de JAR et qui initialise des milliers de classes peut prendre pas mal de temps au d\u00e9marrage d\u00fb \u00e0 ces phases, ce qui est encore plus probl\u00e9matique pour les frameworks de microservice comme Spring qui ont tendances \u00e0 scanner des milliers de beans au d\u00e9marrage. M\u00eame quand ces \u00e9tapes sont faites de mani\u00e8re paresseuse, \u00e0 la demande, elles impactent fortement les premi\u00e8res minutes de fonctionnement d’une application menant \u00e0 une performance en pic tardive.<\/p>\n Avec la JEP 483: Ahead-of-Time Class Loading & Linking, il va \u00eatre possible de cr\u00e9er un cache des classes initialis\u00e9es et link\u00e9es, puis de l’utiliser dans une ex\u00e9cution successive de l’application pour en optimiser le d\u00e9marrage.<\/p>\n Contrairement \u00e0 GraalVM qui propose le m\u00eame type de fonctionnalit\u00e9, mais dans un monde cl\u00f4t<\/em>, toutes les fonctionnalit\u00e9s de la JVM sont pr\u00e9serv\u00e9es. Une classe qui n’est pas pr\u00e9sente dans l’archive sera charg\u00e9e dynamiquement par la JVM.<\/p>\n L’utilisation du mode AOT se fait en trois \u00e9tapes : enregistrement des classes \u00e0 inclure dans le cache, cr\u00e9ation du cache, puis utilisation du cache.<\/p>\n Exemple avec une application de type Hello World<\/em> dans une classe unique Une application telle que Spring PetClinic charge et lie environ 21 000 classes au d\u00e9marrage et d\u00e9marre en 4,486 secondes (JDK 23). Avec un cache AOT, elle d\u00e9marre en 2,604 secondes – ce qui repr\u00e9sente une am\u00e9lioration de 42 %. Le cache AOT occupe 130 m\u00e9gaoctets.<\/p>\n Plus d’information dans la JEP 483<\/a>.<\/p>\n Le Security Manager a \u00e9t\u00e9 d\u00e9pr\u00e9ci\u00e9 en Java 17, il est maintenant supprim\u00e9 totalement du JDK !<\/p>\n Le Security Manager \u00e9tait un composant compliqu\u00e9 \u00e0 maintenir avec une empreinte importante dans le code, et certainement un impact en termes de performance (au moins au d\u00e9marrage d’une application jusqu’\u00e0 ce que le JIT en optimise les appels) ; sa suppression a entra\u00een\u00e9 la suppression de plus de 14000 lignes de code !<\/p>\n Il y a eu beaucoup de discussion autour de sa suppression, le Security Manager permettait une forme de s\u00e9curit\u00e9 via des checks r\u00e9alis\u00e9s lors de l’appel de certaines m\u00e9thodes du JDK (ouverture de thread, acc\u00e8s fichiers…), il avait \u00e9t\u00e9 cr\u00e9\u00e9 au d\u00e9part pour s\u00e9curiser l’appel de code non fiable (par exemple, du code externe ex\u00e9cut\u00e9 dynamiquement) entre autres pour les applets (qu’elles reposent en paix). Hors les besoins modernes de s\u00e9curit\u00e9 sont plus complexes et doivent \u00eatre r\u00e9alis\u00e9s via un ensemble d’outils dont la s\u00e9curit\u00e9 p\u00e9riph\u00e9rique et le sandboxing sont les principaux alli\u00e9s. Il est fortement d\u00e9conseill\u00e9 d’ex\u00e9cuter du code non fiable, et si cela est n\u00e9cessaire d’autres techniques doivent \u00eatre mises en oeuvres<\/strong>.<\/p>\n Ce qui est dommage dans la suppression du Security Manager c’est que m\u00eame imparfait, il rendait de nombreux services, entre autres pour les plateformes qui avaient un syst\u00e8me de plugin tel que Kafka Connect, Elasticsearch ou Kestra<\/a> – l\u2019orchestrateur de donn\u00e9e pour lequel je travaille. Un syst\u00e8me de plugin va par d\u00e9finition ex\u00e9cuter du code non fiable, et les autres techniques qui doivent \u00eatre mises en oeuvres<\/strong> ne sont pas fournies en remplacement du Security Manager. La JEP conseille d’ex\u00e9cuter du code non-fiable dans une sandbox (Docker, GraalVM) ou d’impl\u00e9menter des contr\u00f4les d’acc\u00e8s via un agent Java !<\/p>\n Pour moi, c’est assez probl\u00e9matique de supprimer sans aucune solution le Security Manager, il permettait de s\u00e9curiser du code non fiable, ce qui est n\u00e9cessaire pour un syst\u00e8me de plugin. Une partie de ses fonctionnalit\u00e9s auraient pu \u00eatre pr\u00e9serv\u00e9es ou remplac\u00e9es par un syst\u00e8me plus simple. Bien s\u00fbr, je suis ici biais\u00e9 car je vais devoir r\u00e9-impl\u00e9menter les r\u00e8gles de s\u00e9curit\u00e9 de Kestra<\/a> autrement, car nous utilisions le Security Manager.<\/p>\n Stuart Marks a \u00e9crit un article int\u00e9ressant sur la suppression du Security Manager : Detoxifying the JDK Source Code<\/a>.<\/p>\n Plus d’information dans la JEP 486<\/a>.<\/p>\n ZGC est un Garbage Collector (GC) d\u00e9velopp\u00e9 par Oracle et inclus dans OpenJDK. Il r\u00e9duit les temps de pause du GC en effectuant le travail d’\u00e9vacuation en m\u00eame temps que les threads applicatifs en cours d’ex\u00e9cution.<\/p>\n ZGC n’\u00e9tait pas g\u00e9n\u00e9rationnel lors de sa cr\u00e9ation, mais a un mode g\u00e9n\u00e9rationnel depuis Java 21. Cette JEP va supprimer le mode non g\u00e9n\u00e9rationnel pour r\u00e9duire le co\u00fbt de maintenance de ZGC.<\/p>\n Plus d’information dans la JEP 490<\/a>.<\/p>\n Les Virtual threads sont des threads l\u00e9gers, avec un co\u00fbt de cr\u00e9ation et de scheduling faible, qui permettent de faciliter l\u2019\u00e9criture d\u2019application concurrente. Un virtual thread, quand il s’ex\u00e9cute, va \u00eatre mont\u00e9 sur un platform thread (thread OS).<\/p>\n Jusqu’ici, la synchronisation Java (via le mot cl\u00e9 Avec la JEP 491, les virtual threads vont maintenant l\u00e2cher leur platform thread en cas de synchronisation. C’est une \u00e9tape importante pour les virtual threads, car c’\u00e9tait le principal souci de performance qu’on pouvait rencontrer lors de leur utilisation.<\/p>\n Plus d’information dans la JEP 491<\/a>.<\/p>\n JEP 493 r\u00e9duit la taille du JDK d’environ 25 % en permettant \u00e0 l’outil jlink de cr\u00e9er des images d’ex\u00e9cution personnalis\u00e9es sans utiliser les fichiers JMOD du JDK. Cette fonction doit \u00eatre activ\u00e9e lorsque le JDK est construit, tous les fournisseurs de JDK pourraient ne pas l’activer, mais il est probable qu’ils le fassent et que le JDK 24 soient 25% plus petit que les pr\u00e9c\u00e9dentes versions !<\/p>\n Les fichiers JMOD sont les fichiers des modules du JDK utilis\u00e9s par jlink pour cr\u00e9er une image du JDK; or cette image contient elle-m\u00eame les fichiers des modules du JDK qui sont donc dupliqu\u00e9s, les fichiers JMOD ne servant \u00e0 rien.<\/p>\n Plus d’information dans la JEP 493<\/a>.<\/p>\n La JEP 496 fournit une impl\u00e9mentation du m\u00e9canisme d’encapsulation de cl\u00e9s bas\u00e9 sur un module-r\u00e9seau (Module-Lattice en anglais) r\u00e9sistant aux algorithmes quantiques (ML-KEM). Les m\u00e9canismes d’encapsulation de cl\u00e9s (KEM) sont utilis\u00e9s pour s\u00e9curiser les cl\u00e9s sym\u00e9triques sur des canaux de communication non s\u00e9curis\u00e9s \u00e0 l’aide de la cryptographie \u00e0 cl\u00e9 publique. Le ML-KEM a \u00e9t\u00e9 normalis\u00e9 par le National Institute of Standards and Technology (NIST) des \u00c9tats-Unis dans le cadre de la norme FIPS 203<\/a>.<\/p>\n Les algorithmes de type module-r\u00e9seau sont une classe d’algorithme dit post-quantique, ils sont con\u00e7us pour \u00eatre s\u00e9curis\u00e9 contre les futures attaques de l’informatique quantique.<\/p>\n Les algorithmes cryptographiques actuels font appel \u00e0 des probl\u00e8mes de math\u00e9matiques finies (comme la factorisation des grands nombres) qui sont co\u00fbteux en termes de calcul. Casser via brute force ce type d’algorithme pour des cl\u00e9s de grande taille prendrait des milliers d’ann\u00e9es, m\u00eame pour un supercalculateur.<\/p>\n Les ordinateurs quantiques sont th\u00e9oriquement capables de factoriser de grand nombre de mani\u00e8re beaucoup plus rapide gr\u00e2ce \u00e0 l’algorithme de Shor, pour s\u00e9curiser les communications dans un monde o\u00f9 un ordinateur quantique existerait avec un nombre de Qubit suffisant pour factoriser un grand nombre (il faudrait un nombre de Qubit deux fois sup\u00e9rieur \u00e0 la taille de la cl\u00e9), il faut une nouvelle classe d’algorithmes qui se basent sur une preuve math\u00e9matique diff\u00e9rente, c’est l\u00e0 qu’entre en jeux les algorithmes de type module-r\u00e9seau.<\/p>\n Le NIST conseille de mettre en place ces algorithmes d’ici 10 ans, mais il faut savoir que pour l’instant les ordinateurs quantiques sont loin d’avoir le nombre de Qubit n\u00e9cessaire. \u00c0 ce jour, ils ont g\u00e9n\u00e9ralement au plus 64 Qubit alors qu’il en faudrait 1024 pour casser une encryption 512 bits et 4096 pour une encryption 2048 bits. Sans parler des probl\u00e8mes d’exactitude…<\/p>\n Plus d’information sur la cryptographie post quantique dans cet article de Ben Evans : Post-Quantum Cryptography in Java<\/a>.<\/p>\n Plus d’information dans la JEP 496<\/a>.<\/p>\n La JEP 497 fournit une impl\u00e9mentation d’algorithme de signature num\u00e9rique bas\u00e9 sur le module-r\u00e9seau (Module-Lattice en anglais) r\u00e9sistant aux algorithmes quantiques (ML-DSA). Les signatures num\u00e9riques sont utilis\u00e9es pour d\u00e9tecter les modifications non autoris\u00e9es des donn\u00e9es et pour authentifier l’identit\u00e9 des signataires. Il a \u00e9t\u00e9 normalis\u00e9 par le National Institute of Standards and Technology (NIST) des \u00c9tats-Unis dans la norme FIPS 204.<\/p>\n Plus d’information dans la JEP 497<\/a>.<\/p>\n Unsafe<\/strong> est, comme son nom l\u2019indique, une classe interne et non support\u00e9e du JDK qu\u2019il n\u2019est pas sans danger d\u2019appeler. Pour des raisons historiques, de nombreux frameworks bas-niveau utilisaient Unsafe pour des acc\u00e8s m\u00e9moire plus rapide. Gr\u00e2ce aux fonctionnalit\u00e9s VarHandle API (JEP 193<\/a>, depuis Java 9) et Foreign Function & Memory API (JEP 454<\/a>, depuis Java 22), il y a maintenant des remplacements pour les m\u00e9thodes d\u2019Unsafe acc\u00e9dant \u00e0 la m\u00e9moire qui sont aussi performants, mais plus s\u00fbr et support\u00e9.<\/p>\n Toutes ces m\u00e9thodes ont \u00e9t\u00e9 d\u00e9pr\u00e9ci\u00e9es pour suppression dans Java 23, elles sont \u00e0 pr\u00e9sent modifi\u00e9es pour g\u00e9n\u00e9rer un WARNING<\/strong> dans les logs de la JVM lors de leur premi\u00e8re utilisation.<\/p>\n Ce changement \u00e9tait pr\u00e9vu et annonc\u00e9 lors de leur d\u00e9pr\u00e9ciation en Java 23, il est pr\u00e9vu de les d\u00e9grader pour lever une exception en Java 26.<\/p>\n Plus d’information dans la JEP 498<\/a>.<\/p>\n Le port 32-bit pour Windows est supprim\u00e9 dans cette release, mais il reste un port 32-bit pour d’autres OS (Linux). Cette JEP va d\u00e9pr\u00e9cier tous les ports 32-bit pour architecture x86 restant, donc celui pour Linux qui est le seul encore support\u00e9. Elle ne porte pas sur les autres ports 32-bit tel que celui pour ARM32 qui n’est pas d\u00e9pr\u00e9ci\u00e9. L’industrie a depuis longtemps abandonn\u00e9 l’architecture 32-bit x86, Debian planifiant aussi d’en arr\u00eater le support, il est logique d’en planifier l’arr\u00eat du support dans la JVM.<\/p>\n Pour les architectures non support\u00e9es, il existe un port de la JVM sans sp\u00e9cificit\u00e9 d’architecture : le port Zero, qui permettra toujours de faire tourner une JVM sous architecture 32-bit x86.<\/p>\n Plus d’information dans la JEP 501<\/a>.<\/p>\n Les fonctionnalit\u00e9s suivantes sortent de preview (ou du module incubator) et passent en standard :<\/p>\n Pour les d\u00e9tails sur celles-ci, vous pouvez vous r\u00e9f\u00e9rer \u00e0 mes articles pr\u00e9c\u00e9dents.<\/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 24 peuvent \u00eatre trouv\u00e9es dans The Java Version Almanac \u2013 New APIs in Java 24<\/a>.<\/p>\n Comme toutes les nouvelles versions de Java, OpenJDK 24 contient son lot d’optimisation de performance et d’am\u00e9lioration de s\u00e9curit\u00e9.<\/p>\n Vous pouvez vous r\u00e9f\u00e9rer \u00e0 l\u2019article de Sean Mullan pour une liste exhaustive des changements de s\u00e9curit\u00e9 inclus dans cette version : JDK 24 Security Enhancements<\/a>.<\/p>\n Vous pouvez vous r\u00e9f\u00e9rer \u00e0 l’article de Claes Redestad et Per-Ake Minborg pour une liste exhaustive des am\u00e9liorations de performance inclus dans cette version : Performance Improvements in JDK 24<\/a>.<\/p>\n Voici les nouveaux \u00e9v\u00e9nements Java Flight Recorder (JFR) de la JVM :<\/p>\n Vous pouvez retrouver tous les \u00e9v\u00e9nements JFR support\u00e9s dans cette version de Java sur la page JFR Events<\/a>.<\/p>\n Java 24 contient beaucoup de nouveaut\u00e9s, on eut se r\u00e9jouir de voir les Stream Gatherer sortirent de preview, mais il reste beaucoup de fonctionnalit\u00e9s qui semblent bloqu\u00e9es en preview sans aucun changement.<\/p>\n Personnellement, je suis un peu d\u00e9\u00e7u de la suppression sans remplacement du Security Manager, m\u00eame si cela va me donner l’opportunit\u00e9 de jouer avec les agents Java tr\u00e8s prochainement pour le remplacer ;).<\/p>\n Pour retrouver tous les changements de Java 24, se r\u00e9f\u00e9rer aux release notes<\/a>.<\/p>","protected":false},"excerpt":{"rendered":" Maintenant que Java 24 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. Cet article fait partie d\u2019une suite d\u2019article sur les nouveaut\u00e9s des derni\u00e8res versions de Java, pour ceux qui voudraient les lire en voici les liens : Java 23, Java 22, Java 21, Java 20, Java 19, Java 18, Java 17, Java 16, Java 15, Java 14, Java 13,…JEP 404: Generational Shenandoah (Experimental)<\/h2>\n
-XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational<\/code>.<\/p>\nJEP 450: Compact Object Headers (Experimental)<\/h2>\n
Point(int x, int y)<\/code>, bien qu’un int utilise 32 bits, la taille de l\u2019objet Point va \u00eatre de 192 bits, car chaque objet stock dans sa r\u00e9f\u00e9rence un ensemble d’information sur 128 bits.<\/p>\n-XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders<\/code>, la JVM va stocker le header des objets sur 64 bits : 22 bits pour le pointeur de classe, 31 bits pour le hash code, 4 bits r\u00e9serv\u00e9s pour Valhalla et les bits restant comme pr\u00e9c\u00e9demment pour l’\u00e2ge GC et les flags de la JVM.<\/p>\nJEP 472: Prepare to Restrict the Use of JNI<\/h2>\n
--enable-native-access<\/code> est utilis\u00e9e pour l’autoriser. Il est aussi possible d’utiliser l’entr\u00e9e de manifest Enable-Native-Acces<\/code>.<\/p>\n--illegal-native-access<\/code> permet de contr\u00f4ler le comportement de la JVM dans ces cas_l\u00e0. Elle a comme valeur par d\u00e9faut warn<\/code>, et peut prendre les valeurs suivantes :<\/p>\nallow<\/code> : l’utilisation est autoris\u00e9e sans restriction,<\/li>\n\nwarn<\/code> : le d\u00e9faut en Java 24, un warning sera \u00e9crit dans les logs de la JVM,<\/li>\n\ndeny<\/code> : l’utilisation est refus\u00e9e, une exception IllegalCallerException<\/code> sera lev\u00e9e.<\/li>\n<\/ul>\n\nWARNING: A restricted method in java.lang.System has been called\nWARNING: System::load has been called by com.foo.Server in module com.foo (file:\/path\/to\/com.foo.jar)\nWARNING: Use --enable-native-access=com.foo to avoid a warning for callers in this module\nWARNING: Restricted methods will be blocked in a future release unless native access is enabled\n<\/pre>\n
warn<\/code> \u00e0 deny<\/code> dans une future release.<\/p>\nJEP 475: Late Barrier Expansion for G1<\/h2>\n
JEP 478: Key Derivation Function API (Preview)<\/h2>\n
JEP 479: Remove the Windows 32-bit x86 Port<\/h2>\n
JEP 483: Ahead-of-Time Class Loading & Linking<\/h2>\n
Main<\/code> :<\/p>\njava -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf Main<\/code> : lacement de l’application en mode record pour enregistrer les classes \u00e0 charger dans un fichier de configuration app.aotconf<\/strong>.<\/li>\n\njava -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=main.aot<\/code> : utilisation du fichier de configuration app.aotconf<\/strong> pour cr\u00e9er une archive de cache main.aot<\/strong>.<\/li>\n\njava -XX:AOTCache=main.aot Main<\/code> : lancement de l’application avec le cache main.aot<\/strong>.<\/li>\n<\/ol>\nJEP 486: Permanently Disable the Security Manager<\/h2>\n
JEP 490: ZGC: Remove the Non-Generational Mode<\/h2>\n
JEP 491: Synchronize Virtual Threads without Pinning<\/h2>\n
synchronized<\/code>) ne l\u00e2chait pas le platform thread, on disait alors que le platform thread \u00e9tait attach\u00e9 (pinned<\/strong> en anglais) au virtual thread, ce qui limitait grandement la scallabilit\u00e9 des virtual threads si beaucoup d’op\u00e9rations de synchronisation \u00e9taient effectu\u00e9es. Et la synchronisation est utilis\u00e9e \u00e0 de nombreux endroits au sein du JDK (pour les I\/O par exemples), ainsi que dans de nombreuses librairies (clients JDBC par exemple).<\/p>\nJEP 493: Linking Run-Time Images without JMODs<\/h2>\n
JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism<\/h2>\n
JEP 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm<\/h2>\n
JEP 498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe<\/h2>\n
JEP 501: Deprecate the 32-bit x86 Port for Removal<\/h2>\n
Les fonctionnalit\u00e9s qui sortent de preview<\/h2>\n
Les fonctionnalit\u00e9s qui restent en preview<\/h2>\n
void main()<\/code>. Aucun changement.<\/li>\n\nScopedValue.callWhere()<\/code> et ScopedValue.runWhere<\/code> ont \u00e9t\u00e9 supprim\u00e9es, on ne peut dor\u00e9navant utiliser une ScopedValue<\/code> que depuis call(Callable)<\/code> ou run(Runnable)<\/code>.<\/li>\n\nimport module java.base;<\/code>. Changements mineurs.<\/li>\n\ninstanceof<\/code> et les switch<\/code>, et enrichit le pattern matching pour supporter des patterns de types primitifs : dans les instanceof<\/code>, dans les cases des switch<\/code>, et dans la d\u00e9construction d\u2019un record. Aucun changement.<\/li>\n<\/ul>\nDivers<\/h2>\n
Console.println()<\/code> : \u00e9crit une ligne vide dans une console.<\/li>\n\nConsole.readLn()<\/code> : lit une ligne de texte depuis une console.<\/li>\n\nIO.println()<\/code> : \u00e9crit une ligne vide dans la console syst\u00e8me.<\/li>\n\nIO.readLn()<\/code> : lit une ligne de texte depuis la console syst\u00e8me.<\/li>\n\nReader.of(CharSequence)<\/code> : renvoie un lecteur qui lit les caract\u00e8res d’une CharSequence<\/code>. Le lecteur est initialement ouvert et la lecture commence au premier caract\u00e8re de la s\u00e9quence.<\/li>\n\nProcess.waitFor(Duration)<\/code> : fait attendre le thread actuel, si n\u00e9cessaire, jusqu’\u00e0 ce que le processus repr\u00e9sent\u00e9 par cet objet Process<\/code> se termine, ou que la dur\u00e9e d’attente sp\u00e9cifi\u00e9e s’\u00e9coule.<\/li>\n<\/ul>\nDes changements internes, de la performance, et de la s\u00e9curit\u00e9<\/h2>\n
instanceof<\/code>, il met en cache un super type d’une classe. Comme il ne contient qu’une seule entr\u00e9e, si plusieurs threads font des instanceof<\/code> sur des super type diff\u00e9rentes pour la m\u00eame classe, le cache va \u00eatre invalid\u00e9 sans arr\u00eat, ce qui peut avoir des cons\u00e9quences importantes en termes de performance. Ce cache a \u00e9t\u00e9 r\u00e9\u00e9crit par Andrew Haley de chez RedHat qui l’a remplac\u00e9 par un cache via table de hachage (voir #18309<\/a>. Ce probl\u00e8me \u00e9tait nomm\u00e9 type pollution<\/em>; RedHat avait d\u00e9velopp\u00e9 un agent Java pour en d\u00e9tecter les cas probl\u00e9matiques (voir type-pollution-agent<\/a>) et certains frameworks avait m\u00eame impl\u00e9ment\u00e9 des solutions de contournement pour l’\u00e9viter dans les chemins critiques (par exemple pour Quarkus : #28834<\/a>, #28985<\/a> ou #29109<\/a>).<\/li>\n\nString.indexOf()<\/code> a vu une am\u00e9lioration de performance de 1.3x par l’ajout d’un intrinsic utilisant les instructions SIMD.<\/li>\n\nMemorySegment<\/code> ont vu leur performance am\u00e9lior\u00e9e pour des segments de petite taille. Ces op\u00e9rations \u00e9taient impl\u00e9ment\u00e9es en natif via Unsafe<\/code>: pour des petits segments, le co\u00fbt de transition vers du code natif p\u00e9nalisait fortement les performances. Une impl\u00e9mentation en Java a \u00e9t\u00e9 fournie qui est utilis\u00e9e pour les segments de petite taille (par d\u00e9faut moins de 64KB) \u00e0 la place de l’impl\u00e9mentation en code natif.<\/li>\n<\/ul>\nJFR Events<\/h2>\n
NativeMemoryUsageTotalPeak<\/code> : Total des pics d’utilisation de la m\u00e9moire native pour la JVM (GraalVM Native Image uniquement). Il peut ne pas \u00eatre la somme exacte des \u00e9v\u00e9nements NativeMemoryUsagePeak<\/code> en raison du timing.<\/li>\n\nNativeMemoryUsagePeak<\/code> : Utilisation maximale de la m\u00e9moire native pour un type de m\u00e9moire donn\u00e9 dans la JVM (GraalVM Native Image uniquement).<\/li>\n\nSerializationMisdeclaration<\/code> : M\u00e9thodes et champs mal d\u00e9clar\u00e9s pour la s\u00e9rialisation.<\/li>\n\nSwapSpace<\/code> : m\u00e9moire swap de l’OS.<\/li>\n<\/ul>\nConclusion<\/h2>\n