Maintenant que Java 20 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 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 Force est de constater qu’il n’y a pas grand-chose de nouveau dans cette release. Des 6 Java Enhancement Proposals (JEP) qui ont \u00e9t\u00e9 d\u00e9livr\u00e9es, une seule porte sur une nouvelle API du langage : JEP 429 – Scoped Values, les autres sont des it\u00e9rations de fonctionnalit\u00e9s existantes.<\/p>\n La JEP 429 introduit les Scoped Values<\/strong> qui permettent le partage de donn\u00e9es immuables au sein et entre les threads.<\/p>\n Jusqu’ici, pour partager une donn\u00e9e au sein d’un thread, on utilisait des Thread Locals. Ceux-ci sont mutables et n\u00e9cessitent une structure de donn\u00e9e complexe dont le co\u00fbt n’est pas en accord avec les virtual threads qui sont l\u00e9gers et peu ch\u00e8re \u00e0 construire. De plus, ils \u00e9taient parfois la cause de bug, car leur utilisation n’\u00e9tait pas forc\u00e9ment bien comprise.<\/p>\n Le support des thread locals avec Loom \u00e9tant probl\u00e9matique, une nouvelle mani\u00e8re de partager de la donn\u00e9e entre thread a \u00e9t\u00e9 propos\u00e9e qui est immuable et s’interface mieux avec l’API Structured Concurrency : les Scoped Values.<\/p>\n Voici un exemple tr\u00e8s basique :<\/p>\n Il est aussi possible d’appeler A la fin de l’appel de la m\u00e9thode Plus d\u2019information dans la JEP 429<\/a>.<\/p>\n La seconde preview des Record Patterns contient des changements importants, elle m\u00e9rite donc un paragraphe d\u00e9di\u00e9 pour les pr\u00e9senter.<\/p>\n Si vous ne connaissez pas encore les Record Patterns, vous pouvez vous r\u00e9f\u00e9rer \u00e0 mon article Java 19 : Quoi de neuf ?<\/a><\/p>\n Trois changements ont \u00e9t\u00e9 faits :<\/p>\n Le support de l’inf\u00e9rence du type param\u00e9tr\u00e9 pour les patterns de record generic permet d\u2019omettre le type param\u00e9tr\u00e9 dans un record pattern si celui-ci peut \u00eatre inf\u00e9r\u00e9 par le compilateur. \u00c9tonnamment, l’op\u00e9rateur diamond () n’a pas \u00e9t\u00e9 utilis\u00e9, on peut simplement omettre le type param\u00e9tr\u00e9.<\/p>\n Le support des record patterns dans les boucles for (enhanced for statements) permet l’acc\u00e8s direct aux composants d’un record dans le corps d’une boucle for.<\/p>\n Avant la JEP 432, il \u00e9tait possible de nommer un pattern de record pour, en quelque sorte, faire du pattern matching sur le record et ses composants en m\u00eame temps.<\/p>\n Cette possibilit\u00e9 a \u00e9t\u00e9 supprim\u00e9e, le code ci-dessus g\u00e9n\u00e9rera maintenant une erreur \u00e0 la compilation. On ne sait pas encore si c’est d\u00e9finitif ou si elle pourrait revenir prochainement.<\/p>\n Plus d\u2019information dans la JEP 432<\/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 20 peuvent \u00eatre trouv\u00e9es dans The Java Version Almanac \u2013 New APIs in Java 20<\/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 performance, on peut noter plusieurs am\u00e9liorations dans la gestion des I\/O via les classes Thomas Schatzl a contribu\u00e9 une am\u00e9lioration du garbage collector G1 qui n’utilise maintenant plus qu’un seul bitmap pour stocker les informations de liveness des objets de la heap. Ce changement fait baisser la taille de la m\u00e9moire native utilis\u00e9e par G1 d’exactement 1.5% de la taille de la heap. Plus d’information dans cet article qui contient aussi un rappel assez complet sur les diff\u00e9rentes phases de G1 : Concurrent Marking in G1<\/a>. D’autres changements ont \u00e9t\u00e9 fait c\u00f4t\u00e9 Garbage Collector, vous pouvez les retrouver dans cet article de Thomas Schatzl : JDK 20 G1\/Parallel\/Serial GC changes<\/a>.<\/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, les performance des algorithmes de cryptographie, ainsi que l’ajout d’\u00e9v\u00e8nements JFR pour le monitoring de la s\u00e9curit\u00e9. 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 20 Security Enhancements<\/a>.<\/p>\n Cette nouvelle version apporte quelques changements mineurs au pattern matching, et quelques am\u00e9liorations dans la programmation concurrente via la nouvelle API Scoped Values. Donc tr\u00e8s peu de choses par rapport aux pr\u00e9c\u00e9dentes versions. La prochaine version sera aussi la prochaine LTS, on esp\u00e8re que pour celle-ci, une partie des JEP qui sont en preview depuis litt\u00e9ralement des ann\u00e9es seront promues stable.\n<\/p>","protected":false},"excerpt":{"rendered":" Maintenant que Java 20 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 19, Java 18, Java 17, Java 16, Java 15, Java 14, Java 13, Java 12, Java 11,\u00a0Java 10,\u00a0et\u00a0Java 9. Force est…JEP 429 – Scoped Values<\/h2>\n
\nprivate static final ScopedValue USERNAME = ScopedValue.newInstance();\n\nScopedValue.where(USERNAME, \"duke\") \/\/ bind a value to the scope\n \/\/ start a thread that could access this value\n .run(() -> System.out.println(\"User: \" + USERNAME.get()));\n<\/pre>\n
.call()<\/code> avec un Callable<\/code> pour retourner une valeur.<\/p>\nrun()<\/code>, le scoped value n’aura plus de valeur pour le thread, ce qui \u00e9vite tout risque de memory leak.<\/p>\nJEP-432 – Record Patterns (Second Preview)<\/h2>\n
\nrecord Box(T t) {}\n\nstatic void test(Box bo) {\n if (bo instanceof Box(var s)) { \/\/ Inferred to be Box(var s)\n System.out.println(\"String \" + s);\n }\n}\n<\/pre>\n\nrecord Point(int x, int y) {}\n\nstatic void dump(Point[] pointArray) {\n for (Point(var x, var y) : pointArray) { \/\/ Record Pattern in header!\n System.out.println(\"(\" + x + \", \" + y + \")\");\n }\n}\n<\/pre>\n\nrecord Point(int x, int y) {}\n\nstatic void noMorePossible(Point p) {\n if(p instanceof Point(int x, int y) p) {\n System.out.println(\"x=\" + x + \" y=\" + y + \"for the point \" + p);\n }\n}\n<\/pre>\nLes fonctionnalit\u00e9s qui restent en preview<\/h2>\n
IncompatibleClassChangeError<\/code> et sera maintenant de type MatchException<\/code>.<\/li>\n\nDivers<\/h2>\n
URI.toURL()<\/code> pour construire un objet de type URL depuis une URI.<\/li>\n\nFloat.float16ToFloat(short)<\/code> : Renvoie la valeur flottante la plus proche de la valeur num\u00e9rique de l’argument, qui est une valeur binary16 \u00e0 virgule flottante encod\u00e9e dans un short.<\/li>\n\nFloat.floatToFloat16(float)<\/code> : Renvoie la valeur binary16 \u00e0 virgule flottante, encod\u00e9e dans le short le plus proche de l’argument.<\/li>\n<\/ul>\nDes changements internes, de la performance, et de la s\u00e9curit\u00e9<\/h2>\n
BufferedInputStream<\/code>, PushbackInputStream<\/code>, SequenceInputStream<\/code> et ZipInputStream<\/code>.<\/p>\nConclusion<\/h2>\n