{"id":165062,"date":"2026-03-17T23:11:55","date_gmt":"2026-03-17T21:11:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-java-se-26-i-openjdk-26-proekt-po-integraczii-podderzhki-javascript-i-python-v-jvm"},"modified":"2026-03-17T23:11:55","modified_gmt":"2026-03-17T21:11:55","slug":"vypusk-java-se-26-i-openjdk-26-proekt-po-integraczii-podderzhki-javascript-i-python-v-jvm","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/vypusk-java-se-26-i-openjdk-26-proekt-po-integraczii-podderzhki-javascript-i-python-v-jvm","title":{"rendered":"Sortie de Java SE 26 et OpenJDK 26. Projet d'int\u00e9gration du support de JavaScript et Python dans la JVM.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Apr\u00e8s six mois de d\u00e9veloppement, Oracle a publi\u00e9 la plateforme Java SE 26 (Java Platform, Standard Edition 26), dont le projet OpenJDK est utilis\u00e9 comme impl\u00e9mentation de r\u00e9f\u00e9rence. \u00c0 l'exception de la suppression de certaines fonctionnalit\u00e9s obsol\u00e8tes, Java SE 26 conserve la compatibilit\u00e9 ascendante avec les versions pr\u00e9c\u00e9dentes de la plateforme Java \u2014 la plupart des projets Java \u00e9crits pr\u00e9c\u00e9demment fonctionneront sans modifications avec cette nouvelle version. Les distributions pr\u00eates \u00e0 installer de Java SE 26 (JDK, JRE et Server JRE) sont pr\u00e9par\u00e9es pour Linux (x86_64, AArch64), Windows (x86_64) et macOS (x86_64, AArch64). L'impl\u00e9mentation de r\u00e9f\u00e9rence de Java SE 26, d\u00e9velopp\u00e9e dans le cadre du projet OpenJDK, est enti\u00e8rement ouverte sous la licence GPLv2 avec des exceptions GNU ClassPath autorisant le liaisonnement dynamique avec des produits commerciaux. <\/p>\n
Java SE 26 est class\u00e9 parmi les versions avec un support standard limit\u00e9, les mises \u00e0 jour seront publi\u00e9es jusqu'\u00e0 la prochaine version. Pour une branche \u00e0 long terme (LTS), il convient d'utiliser Java SE 25, Java SE 21 ou Java SE 17, dont les mises \u00e0 jour seront publi\u00e9es jusqu'en 2033, 2031 et 2029 respectivement (publiquement disponibles jusqu'en septembre 2030, 2028 et 2026). Le support prolong\u00e9 de la branche LTS Java SE 8 durera jusqu'en 2030, tandis que Java SE 11 le sera jusqu'en 2032. <\/p>\n
Parmi les changements dans Java SE 26 (1, 2, 3, 4) : <\/p>\n
\n
Il a \u00e9t\u00e9 impl\u00e9ment\u00e9 un avertissement lors de l'utilisation de la r\u00e9flexion profonde pour modifier des champs marqu\u00e9s avec le mot-cl\u00e9 \u00ab final \u00bb. \u00c0 l'avenir, il est pr\u00e9vu de d\u00e9sactiver par d\u00e9faut les fonctionnalit\u00e9s non s\u00e9curis\u00e9es du langage et, entre autres, de rendre les champs marqu\u00e9s comme final compl\u00e8tement non modifiables, en supprimant le contournement pour leur modification via la r\u00e9flexion profonde (API Reflection).\n
L'API Applet (java.applet.Applet*, javax.swing.JApplet) a \u00e9t\u00e9 supprim\u00e9e, utilis\u00e9e pour ex\u00e9cuter des applications Java dans le navigateur. Cette API a perdu sa pertinence apr\u00e8s la cessation du support du plugin Java pour les navigateurs et a \u00e9t\u00e9 d\u00e9clar\u00e9e obsol\u00e8te en 2021.\n
Il est maintenant possible d'utiliser un cache pr\u00e9-g\u00e9n\u00e9r\u00e9 (AOT \u2014 ahead-of-time) avec n'importe quel ramasse-miettes, y compris ZGC (Z Garbage Collector). Ce changement implique le support du chargement s\u00e9quentiel des objets Java mis en cache en m\u00e9moire, utilisant un format universel et ind\u00e9pendant du ramasse-miettes au lieu d'un mappage direct vers des repr\u00e9sentations sp\u00e9cifiques en m\u00e9moire du cache. L'utilisation du cache AOT r\u00e9duit le temps de d\u00e9marrage et acc\u00e9l\u00e8re le r\u00e9chauffement (warmup) de la machine virtuelle HotSpot.\n
Le client HTTP API a \u00e9t\u00e9 mis \u00e0 jour pour supporter le protocole HTTP\/3, permettant aux applications et biblioth\u00e8ques d'acc\u00e9der aux serveurs via HTTP\/3 apr\u00e8s des modifications minimales du code.\n
Les performances du ramasse-miettes G1 ont \u00e9t\u00e9 am\u00e9lior\u00e9es gr\u00e2ce \u00e0 une r\u00e9duction des blocages pour synchroniser les threads d'application avec les threads du ramasse-miettes.\n
Une seconde version pr\u00e9liminaire de l'API pour l'encodage et le d\u00e9codage d'objets avec des cl\u00e9s cryptographiques, des certificats et des listes de certificats r\u00e9voqu\u00e9s a \u00e9t\u00e9 propos\u00e9e, utilisant le format PEM (Pivacy-Enhanced Mail).\n
Une sixi\u00e8me version pr\u00e9liminaire de l'API pour la concurrence structur\u00e9e (Structured Concurrency) a \u00e9t\u00e9 propos\u00e9e pour test, simplifiant le d\u00e9veloppement d'applications multithread en traitant plusieurs t\u00e2ches ex\u00e9cut\u00e9es dans diff\u00e9rents threads comme un seul bloc.\n
Une deuxi\u00e8me \u00e9dition b\u00eata de l'API Lazy Constants a \u00e9t\u00e9 ajout\u00e9e pour travailler avec des objets contenant des donn\u00e9es immuables et trait\u00e9s dans la JVM comme des constantes. Ces objets b\u00e9n\u00e9ficient d'optimisations de performance similaires \u00e0 celles des champs avec le mot-cl\u00e9 \u00ab final \u00bb. Contrairement \u00e0 \u00ab final \u00bb, la nouvelle API s\u00e9pare la cr\u00e9ation de valeurs constantes et leur initialisation, garantissant que la valeur ne peut \u00eatre initialis\u00e9e qu'une seule fois, r\u00e9duisant le temps de d\u00e9marrage des programmes et permettant d'appliquer dans le code utilisateur des optimisations de pliage de constantes, utilis\u00e9es auparavant uniquement dans le code interne du JDK. \n class Application { \n \/\/ Avant : \n \/\/ static final UserService USERS = new UserService(); \n \/\/ Maintenant, on peut : \n static final StableValue USERS = StableValue.of(); \n public static UserService users() { \n return USERS.orElseSet(UserService::new); \n } \n }\n
Dans le m\u00e9canisme de correspondance de motif, une quatri\u00e8me version pr\u00e9liminaire a propos\u00e9 la possibilit\u00e9 d'utiliser des types primitifs (int, byte, char et d'autres types de base qui ne sont pas des objets) dans tous les types de motifs, dans l'op\u00e9rateur \u00ab instanceof \u00bb et dans les blocs \u00ab switch \u00bb. \n switch (x.getStatus()) { \n case 0 -> \u00ab okay \u00bb; \n case 1 -> \u00ab warning \u00bb; \n case 2 -> \u00ab error \u00bb; \n case int i -> \u00ab unknown status: \u00bb + i; \n } \n if (i instanceof byte b) { \n \u2026 b \u2026 \n }\n
Une onzi\u00e8me impl\u00e9mentation test de l'API Vector a \u00e9t\u00e9 propos\u00e9e, fournissant des fonctions pour les calculs vectoriels, qui sont effectu\u00e9s \u00e0 l'aide des instructions vectorielles des processeurs x86_64 et AArch64 et permettent d'appliquer simultan\u00e9ment des op\u00e9rations \u00e0 plusieurs valeurs (SIMD). Contrairement aux capacit\u00e9s d'auto-vectorisation des op\u00e9rations scalaires fournies par le compilateur JIT HotSpot, la nouvelle API permet de g\u00e9rer explicitement la vectorisation pour le traitement parall\u00e8le des donn\u00e9es. <\/ul>\n
De plus, Oracle a annonc\u00e9 le projet Detroit, qui se d\u00e9veloppera dans le cadre d'OpenJDK et vise \u00e0 am\u00e9liorer la portabilit\u00e9 entre Java, JavaScript et Python. Dans le cadre de ce projet, il est pr\u00e9vu de permettre l'int\u00e9gration dans le runtime JVM avec le moteur JavaScript V8 et l'interpr\u00e9teur CPython. Auparavant, Oracle avait d\u00e9j\u00e0 d\u00e9velopp\u00e9 le moteur JavaScript Nashorn, fonctionnant au-dessus de la machine virtuelle JVM, mais a arr\u00eat\u00e9 le projet en raison de la difficult\u00e9 \u00e0 d\u00e9velopper une impl\u00e9mentation distincte de JavaScript dans un contexte o\u00f9 l'\u00e9cosyst\u00e8me principal est li\u00e9 au moteur V8. <\/p>\n
Il convient \u00e9galement de noter la publication d'une mise \u00e0 jour de la plateforme pour la cr\u00e9ation d'applications avec interface graphique JavaFX 26. Dans les prochaines heures, la sortie de la machine virtuelle universelle GraalVM 26, prenant en charge l'ex\u00e9cution d'applications en JavaScript (Node.js), Python, Ruby, R, ainsi que tous les langages pour JVM (Java, Scala, Clojure, Kotlin) et les langages pour lesquels un bitcode LLVM peut \u00eatre g\u00e9n\u00e9r\u00e9 (C, C++, Rust) est \u00e9galement attendue. \n Source : opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"