Apr\u00e8s Java 25 et ses 18 JEPs, Java 26 arrive avec un petit nombre de JEPs, 10, avec tr\u00e8s peu de nouvelles fonctionnalit\u00e9s.<\/p>\n
JEP 500: Prepare to Make Final Mean Final<\/h2>\n
Un champ final est cens\u00e9 ne jamais \u00eatre modifi\u00e9 apr\u00e8s son initialisation.\nMais h\u00e9las, la r\u00e9flexion profonde (deep reflection) permet de rendre accessible un champ final pour pouvoir ensuite le modifier via la m\u00e9thode De plus, certaines optimisations de la JVM ne peuvent s’appliquer aux champs finaux tels que le constant folding<\/em> du Just In Time compiler (JIT), une optimisation qui \u00e9value une expression constante une seule fois plut\u00f4t que chaque fois qu’elle est utilis\u00e9e.<\/p>\n Les records interdisent d\u00e9j\u00e0 la modification de champs finaux.<\/p>\n La JEP 500 va \u00e9mettre un warning dans les logs de la JVM la premi\u00e8re fois qu’un champ final est modifi\u00e9 via r\u00e9flexion profonde.<\/p>\n Cela peut \u00eatre contr\u00f4l\u00e9 via l’option JVM Une future release de Java passera le comportement par d\u00e9faut \u00e0 Il est possible de s\u00e9lectivement autoriser la modification de champs finaux via l’option JVM Plus d’informations dans la \u00a0JEP 500<\/a>.<\/p>\n Supprime l’API des applets qui avait \u00e9t\u00e9 d\u00e9pr\u00e9ci\u00e9e pour suppression en Java 17.<\/p>\n Les navigateurs actuels ne supportent de toute fa\u00e7on plus les applets depuis longtemps.<\/p>\n Plus d’informations dans la \u00a0JEP 504<\/a>.<\/p>\n La JEP 483: Ahead-of-Time Class Loading & Linking<\/a> a introduit en Java 24 la possibilit\u00e9 de cr\u00e9er un cache AOT (Ahead of Time \u2013 avant le lancement de l\u2019application) contenant les classes d\u00e9j\u00e0 charg\u00e9es et li\u00e9es d\u2019une application pour am\u00e9liorer son temps de d\u00e9marrage.<\/p>\n Celui-ci a \u00e9t\u00e9 enrichi en Java 25 avec les informations de profiling des m\u00e9thodes via la JEP 515: Ahead-of-Time Method Profiling<\/a>.<\/p>\n En Java 26, ce cache a \u00e9t\u00e9 am\u00e9lior\u00e9 pour stocker les objets de mani\u00e8re agnostique au GC, permettant un support pour tous les GC, et surtout l’utilisation d’un cache AOT par une JVM utilisant un GC diff\u00e9rent de celui utilis\u00e9 lors de la cr\u00e9ation du cache.<\/p>\n Plus d’informations dans la \u00a0JEP 516<\/a>.<\/p>\n La JEP 517 apporte le support d’HTTP\/3<\/strong> dans le client HTTP du JDK.<\/p>\n Le client HTTP du JDK utilise toujours HTTP\/2 par d\u00e9faut.<\/p>\n Pour utiliser HTTP\/3 il faut s\u00e9lectionner cette version lors de la cr\u00e9ation du client HTTP :<\/p>\n Plus d’informations dans la \u00a0JEP 517<\/a>.<\/p>\n G1<\/strong> est le garbage collector (GC) par d\u00e9faut, mais il est parfois moins performant que le ParallelGC<\/strong> car pour r\u00e9aliser une partie de son travail de mani\u00e8re concurrente \u00e0 l’application, il n\u00e9cessite de partager les ressources CPU avec les threads applicatifs et de se coordonner avec eux.<\/p>\n La JEP 522 augmente \u00e0 la fois le d\u00e9bit et la latence des applications en r\u00e9duisant la quantit\u00e9 de synchronisation requise entre les threads d’application et les threads GC. Plus pr\u00e9cis\u00e9ment la write barrier<\/em> de G1 a \u00e9t\u00e9 modifi\u00e9e pour ne plus synchroniser sur la card table<\/em> via l’ajout d’une seconde card table<\/em>. Sans trop entrer dans les d\u00e9tails, la write barrier<\/em> est un bout de code appel\u00e9 \u00e0 chaque fois que la r\u00e9f\u00e9rence d’un objet est stock\u00e9e dans un champ, permettant \u00e0 G1 de tracer les allocations sans arr\u00eater les threads applicatifs. Enlever cette synchronisation va r\u00e9duire le co\u00fbt de G1 \u00e0 chaque \u00e9criture et donc am\u00e9liorer le d\u00e9bit de l’application.<\/p>\n Plus d’informations dans la \u00a0JEP 522<\/a>.<\/p>\n La nouvelle m\u00e9thode Les UUIDv7 sont cr\u00e9\u00e9es en attribuant un timestamp Unix en millisecondes dans les 48 bits les plus significatifs, en attribuant la version requise (4 bits) et la variante (2 bits) et en remplissant les 74 bits restants avec des bits al\u00e9atoires.<\/p>\n La caract\u00e9ristique principale des UUIDv7 est qu’ils sont monotones (chaque valeur suivante est sup\u00e9rieure \u00e0 la valeur pr\u00e9c\u00e9dente). Cela est d\u00fb au fait que la valeur d’horodatage fait partie de l’UUID.<\/p>\n Le grand avantage des UUIDv7 est qu’ils sont naturellement triables ce qui en fait un bon choix pour des identifiants de base de donn\u00e9es, comblant une des lacunes des UUID de version pr\u00e9c\u00e9dente. Tout en restant sur 128 bits, donc compatible avec les champs de type UUID pr\u00e9c\u00e9dents.<\/p>\n Les fonctionnalit\u00e9s suivantes sortent de preview (ou du module incubator) et passent en standard :<\/p>\n Aucune !<\/em><\/strong><\/p>\n C’est assez rare pour le surligner. Une partie des fonctionnalit\u00e9s qui sont en preview depuis longtemps sont bloqu\u00e9es en attente du projet Valhalla.<\/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 26 peuvent \u00eatre trouv\u00e9es dans The Java Version Almanac \u2013 New APIs in Java 26<\/a>.<\/p>\n Comme toutes les nouvelles versions de Java, OpenJDK 25 contient son lot d’optimisations de performance et d’am\u00e9liorations de s\u00e9curit\u00e9.<\/p>\n C\u00f4t\u00e9 performance, pas de gros changement, mais pas mal de tous les petits changements. J’ai not\u00e9 celui-ci qui am\u00e9liore les performances de C\u00f4t\u00e9 s\u00e9curit\u00e9 je n’ai riens not\u00e9 pour le moment mais je metterais \u00e0 jour l’article si n\u00e9cessaire.<\/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 On reste clairement sur sa faim; cette release apporte tr\u00e8s peu de nouvelles fonctionnalit\u00e9s et la plupart des fonctionnalit\u00e9s d\u00e9j\u00e0 en preview ou incubator module le restent.\nOn peut quand m\u00eame noter le support de HTTP\/3 et UUIDv7 qui sont les bienvenues pour le d\u00e9veloppement d’applications modernes.<\/p>\n Comme toujours, on se languit du projet Valhalla… bien que de nouvelles rumeurs<\/a> sont sorties et pr\u00e9disent une inclusion dans Java 28 des premi\u00e8res fonctionnalit\u00e9s li\u00e9e au project Valhalla qui sont les Value Classes and Objects<\/a> !<\/p>\nField.setAccessible(true)<\/code>.\nModifier un champ final casse l’int\u00e9grit\u00e9 de la JVM car cela contrevient \u00e0 l’intention du d\u00e9veloppeur, avec tous les risques de s\u00e9curit\u00e9 que cela peut engendrer.<\/p>\n\nWARNING: Final field f in p.C has been [mutated\/unreflected for mutation] by class com.foo.Bar.caller in module N (file:\/path\/to\/foo.jar)\nWARNING: Use --enable-final-field-mutation=N to avoid a warning\nWARNING: Mutating final fields will be blocked in a future release unless final field mutation is enabled\n<\/pre>\n
--illegal-final-field-mutation<\/code> qui peut prendre les valeurs :<\/p>\n\n
allow<\/code> : permet la modification de champs finaux.<\/li>\nwarn<\/code> : \u00e9met un warning dans les logs de la JVM la premi\u00e8re fois qu’un champ final est modifi\u00e9, c’est le comportement par d\u00e9faut en Java 26.<\/li>\ndebug<\/code> : identique \u00e0 warn<\/code> mais va inclure en plus la stack trace.<\/li>\ndeny<\/code> : interdit la modification de champs finaux.<\/li>\n<\/ul>\ndeny<\/code>.<\/p>\n--enable-final-field-mutation=M1,M2<\/code> qui prend en param\u00e8tre la liste des modules \u00e0 autoriser.<\/p>\nJEP 504: Remove the Applet API<\/h2>\n
JEP 516: Ahead-of-Time Object Caching with Any GC<\/h2>\n
JEP 517: HTTP\/3 for the HTTP Client API<\/h2>\n
\nvar client = HttpClient.newBuilder()\n .version(HttpClient.Version.HTTP_3)\n .build();\n<\/pre>\n
JEP 522: G1 GC: Improve Throughput by Reducing Synchronization<\/h2>\n
UUIDv7 support<\/h2>\n
UUID.ofEpochMillis(long)<\/code> permet de cr\u00e9er un UUID type 7<\/strong> (UUIDv7) depuis un timestamp Unix Epoch.<\/p>\n![\"uuidv7\"](\"\/wordpress\/wp-content\/uploads\/uuidv7.webp\" "\\"\\"")
\nLes fonctionnalit\u00e9s qui sortent de preview<\/h2>\n
Les fonctionnalit\u00e9s qui restent en preview<\/h2>\n
PEMEncoder<\/code> et PEMDecoder<\/code> proposent toujours la m\u00eame API.<\/li>\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. Deux changements : am\u00e9lioration de la d\u00e9finition de l’exactitude inconditionnelle<\/a> et application de contr\u00f4les de dominance<\/a> plus stricts dans les switch, ce qui peut mener le compilateur \u00e0 rejeter plus de cas qu’auparavant.<\/li>\n<\/ul>\nDivers<\/h2>\n
Process.close()<\/code> : Ferme tous les flux de lecture et d’\u00e9criture et attend la fin du processus. De plus Process<\/code> impl\u00e9mente AutoCloseable<\/code> ce qui fait qu’il peut \u00eatre utilis\u00e9 dans un try-with-resources<\/strong>.<\/li>\nString.compareToFoldCase()<\/code> et String.equalsToFoldCase()<\/code> : impl\u00e9mentation d’equals<\/code> et compareTo<\/code> qui utilisent le case folding<\/strong> d’Unicode.<\/li>\nBigInteger.rootn()<\/code> et BigInteger.rootnAndRemainder()<\/code> : Renvoie la racine enti\u00e8re n-i\u00e8me.<\/li>\nDuration.MAX<\/code> et Duration.MIN<\/code> : dur\u00e9es maximales et minimales support\u00e9es.<\/li>\nInstant.plusSaturating()<\/code> : Renvoie une copie de cet instant plus la dur\u00e9e sp\u00e9cifi\u00e9e, avec une s\u00e9mantique satur\u00e9e. Si le r\u00e9sultat est avant MIN, renvoie MIN; si le r\u00e9sultat est apr\u00e8s MAX, renvoie MAX; sinon, renvoie plus()<\/code>.<\/li>\nThreadLocalRandom.nextGaussian()<\/code> : Renvoie un double choisi de mani\u00e8re pseudo-al\u00e9atoire \u00e0 partir d’une distribution gaussienne.<\/li>\nComparator.min(Object, Object)<\/code> et Comparator.max(Object, Object)<\/code> : retourne le plus petit ou plus grand objet entre les deux objets pass\u00e9s en param\u00e8tre.<\/li>\nHttpRequest.BodyHandlers.ofFileChannel()<\/code> : Renvoie un BodyHandler<\/code> depuis un FileChannel<\/code>.<\/li>\n<\/ul>\nDes changements internes, de la performance, et de la s\u00e9curit\u00e9<\/h2>\n
ArrayList.addAll()<\/code> en ajoutant un fast-path au cas o\u00f9 la collection est elle-m\u00eame une ArrayList<\/code> qui va copier le tableau sous-jacent, plus d’information dans la PR #28116<\/a>.<\/p>\nJFR Events<\/h2>\n
StringDeduplication<\/code> : pas de description.<\/li>\nFinalFieldMutation<\/code> : pas de description.<\/li>\n<\/ul>\nConclusion<\/h2>\n