{"id":99453,"date":"2021-03-17T04:22:35","date_gmt":"2021-03-17T02:22:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-java-se-16"},"modified":"2021-03-17T04:22:35","modified_gmt":"2021-03-17T02:22:35","slug":"vypusk-java-se-16","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/news\/vypusk-java-se-16","title":{"rendered":"Publication de Java SE 16","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Apr\u00e8s six mois de d\u00e9veloppement, Oracle a lanc\u00e9 la plateforme Java SE 16 (Java Platform, Standard Edition 16), dont l'impl\u00e9mentation de r\u00e9f\u00e9rence est le projet open source OpenJDK. Java SE 16 maintient la compatibilit\u00e9 descendante avec les versions ant\u00e9rieures de la plateforme Java, tous les projets Java pr\u00e9c\u00e9demment \u00e9crits fonctionneront sans modifications sous la nouvelle version. Les versions pr\u00eates \u00e0 installer de Java SE 16 (JDK, JRE et Server JRE) sont pr\u00e9par\u00e9es pour Linux (x86_64, AArch64), Windows et macOS. L'impl\u00e9mentation de r\u00e9f\u00e9rence de Java 16 d\u00e9velopp\u00e9e dans le cadre du projet OpenJDK est enti\u00e8rement ouverte sous la licence GPLv2 avec des exceptions GNU ClassPath, permettant le lien dynamique avec des produits commerciaux. <\/p>\n
Java SE 16 est class\u00e9 comme une version avec un cycle de support r\u00e9gulier, des mises \u00e0 jour seront publi\u00e9es jusqu'\u00e0 la prochaine version. Pour une branche avec support \u00e0 long terme (LTS), il est recommand\u00e9 d'utiliser Java SE 11, avec des mises \u00e0 jour publi\u00e9es jusqu'en 2026. La prochaine version LTS est pr\u00e9vue pour septembre 2021. Rappelons qu'\u00e0 partir de la version Java 10, le projet a adopt\u00e9 un nouveau processus de d\u00e9veloppement, impliquant un cycle de cr\u00e9ation de nouvelles versions plus court. De nouvelles fonctionnalit\u00e9s sont d\u00e9sormais d\u00e9velopp\u00e9es dans une branche principale mise \u00e0 jour en permanence, dans laquelle les modifications pr\u00eates sont incluses et des branches pour la stabilisation des nouvelles versions en sont d\u00e9riv\u00e9es tous les six mois. <\/p>\n
Pour la pr\u00e9paration de la nouvelle version, le d\u00e9veloppement a \u00e9t\u00e9 transf\u00e9r\u00e9 du syst\u00e8me de gestion de versions Mercurial vers Git et la plateforme de collaboration GitHub. On s'attend \u00e0 ce que cette migration am\u00e9liore la performance des op\u00e9rations sur le r\u00e9f\u00e9rentiel, accroisse l'efficacit\u00e9 du stockage, garantisse l'acc\u00e8s aux modifications tout au long de l'histoire du projet, am\u00e9liore le support des r\u00e9visions de code et utilise l'API pour l'automatisation des flux de travail. De plus, l'utilisation de Git et GitHub rend le projet plus attrayant pour les d\u00e9butants et les d\u00e9veloppeurs habitu\u00e9s \u00e0 Git. <\/p>\n
Parmi les nouveaut\u00e9s de Java 16, on peut noter : <\/p>\n
\n
Un module exp\u00e9rimental jdk.incubator.vector a \u00e9t\u00e9 ajout\u00e9, mettant en \u0153uvre l'API Vector qui fournit des fonctionnalit\u00e9s pour les calculs vectoriels utilisant des instructions vectorielles des processeurs x86_64 et AArch64, permettant 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.\n
Dans le code JDK et la VM HotSpot, \u00e9crit en C++, il est d\u00e9sormais possible d'utiliser les fonctionnalit\u00e9s introduites dans la sp\u00e9cification C++14. Auparavant, seuls les standards C++98\/03 \u00e9taient autoris\u00e9s.\n
Le ramasse-miettes ZGC (Z Garbage Collector), fonctionnant en mode passif et minimisant autant que possible les d\u00e9lais dus \u00e0 la collecte des ordures, a \u00e9t\u00e9 am\u00e9lior\u00e9 pour permettre le traitement parall\u00e8le des piles de threads sans suspendre l'ex\u00e9cution des threads d'application. Dans ZGC, seules les op\u00e9rations n\u00e9cessitant une suspension, qui ont des d\u00e9lais constants ne d\u00e9passant g\u00e9n\u00e9ralement pas quelques centaines de microsecondes, subsistent.\n
Les classes SocketChannel, ServerSocketChannel et java.nio.channels ont ajout\u00e9 la prise en charge des sockets Unix (AF_UNIX).\n
Un port pour la distribution Linux Alpine avec la biblioth\u00e8que standard C musl, populaire dans les environnements de conteneurs, de microservices, d'applications cloud et embarqu\u00e9es, a \u00e9t\u00e9 r\u00e9alis\u00e9. Ce port propos\u00e9 dans ces environnements permet d'ex\u00e9cuter des programmes Java comme des applications classiques. De plus, gr\u00e2ce \u00e0 jlink, il est possible d'\u00e9liminer tous les modules non utilis\u00e9s et de former un environnement minimal suffisant pour ex\u00e9cuter l'application, cr\u00e9ant ainsi des images compactes sp\u00e9cifiques \u00e0 chaque application.\n
Un m\u00e9canisme Elastic Metaspace a \u00e9t\u00e9 impl\u00e9ment\u00e9 pour optimiser les op\u00e9rations d'allocation et de d\u00e9sallocation de m\u00e9moire pour les m\u00e9tadonn\u00e9es de classes (metaspace) dans la JVM HotSpot. L'utilisation d'Elastic Metaspace r\u00e9duit la fragmentation de la m\u00e9moire, diminue les co\u00fbts dans le chargeur de classes et am\u00e9liore les performances des applications serveur de longue dur\u00e9e gr\u00e2ce \u00e0 un retour plus rapide \u00e0 l'OS de la m\u00e9moire occup\u00e9e par des m\u00e9tadonn\u00e9es de classes inutilis\u00e9es. Une option «-XX:MetaspaceReclaimPolicy=(balanced|aggressive|none)» a \u00e9t\u00e9 propos\u00e9e pour choisir le mode de lib\u00e9ration de m\u00e9moire apr\u00e8s le d\u00e9chargement des classes.\n
Ajout d'un port JDK pour les syst\u00e8mes Windows fonctionnant sur du mat\u00e9riel bas\u00e9 sur l'architecture AArch64.\n
Proposition d'une troisi\u00e8me version pr\u00e9liminaire de l'API Foreign-Memory Access, permettant aux applications Java d'acc\u00e9der de mani\u00e8re s\u00e9curis\u00e9e et efficace aux zones m\u00e9moire en dehors du tas Java, en manipulant les nouvelles abstractions MemorySegment, MemoryAddress et MemoryLayout.\n
Mise en \u0153uvre d'une API exp\u00e9rimentale Foreign Linker, offrant un acc\u00e8s depuis Java au code natif. Avec l'API Foreign-Memory, cette nouvelle interface facilite consid\u00e9rablement la cr\u00e9ation de liaisons avec des biblioth\u00e8ques partag\u00e9es ordinaires.\n
Ajout de l'outil jpackage, permettant de cr\u00e9er des packages pour des applications Java autonomes. Cet outil est bas\u00e9 sur javapackager de JavaFX et permet de g\u00e9n\u00e9rer des packages dans des formats natifs pour diff\u00e9rentes plateformes (msi et exe pour Windows, pkg et dmg pour macOS, deb et rpm pour Linux). Les packages incluent toutes les d\u00e9pendances n\u00e9cessaires.\n
L'encapsulation stricte de tous les \u00e9l\u00e9ments internes du JDK est activ\u00e9e par d\u00e9faut, sauf pour les API critiques comme sun.misc.Unsafe. La valeur de l'option «—illegal-access» est d\u00e9sormais d\u00e9finie par d\u00e9faut sur «deny» au lieu de «permit», ce qui entra\u00eenera le blocage des tentatives d'acc\u00e8s au code pour la plupart des classes, m\u00e9thodes et champs internes. Pour contourner cette restriction, veuillez utiliser l'option «—illegal-access=permit».\n
L'impl\u00e9mentation de la correspondance de mod\u00e8les dans l'op\u00e9rateur «instanceof» a \u00e9t\u00e9 stabilis\u00e9e, permettant de d\u00e9finir imm\u00e9diatement une variable locale pour acc\u00e9der \u00e0 la valeur v\u00e9rifi\u00e9e. Par exemple, vous pouvez \u00e9crire directement «if (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}» sans avoir \u00e0 d\u00e9finir explicitement «String s = (String) obj». Avant : if (obj instanceof Group) { Group group = (Group) obj; var entries = group.getEntries(); } Maintenant, vous pouvez vous passer de la d\u00e9finition «Group group = (Group) obj» : if (obj instanceof Group group) { var entries = group.getEntries(); }\n
L'impl\u00e9mentation du mot-cl\u00e9 «record» a \u00e9t\u00e9 stabilis\u00e9e, fournissant une forme compacte pour d\u00e9finir des classes, permettant de se passer de la d\u00e9finition explicite de divers m\u00e9thodes de bas niveau telles que equals(), hashCode() et toString(), dans les cas o\u00f9 les donn\u00e9es sont uniquement stock\u00e9es dans des champs, dont le comportement ne change pas. Lorsqu'une classe utilise des impl\u00e9mentations typiques des m\u00e9thodes equals(), hashCode() et toString(), il est possible de s'en passer : public record BankTransaction(LocalDate date, double amount, String description) {}\n
Cette d\u00e9claration entra\u00eenera l'ajout automatique des impl\u00e9mentations des m\u00e9thodes equals(), hashCode() et toString() en plus du constructeur et des m\u00e9thodes contr\u00f4lant la modification des donn\u00e9es (getter). <\/p>\n
Une deuxi\u00e8me version pr\u00e9liminaire des classes et interfaces scell\u00e9es («sealed») a \u00e9t\u00e9 propos\u00e9e, qui ne peuvent pas \u00eatre utilis\u00e9es par d'autres classes et interfaces pour l'h\u00e9ritage, l'extension ou la red\u00e9finition de l'impl\u00e9mentation. Les classes scell\u00e9es offrent \u00e9galement une mani\u00e8re plus d\u00e9clarative de restreindre l'utilisation de la superclasse, compar\u00e9e aux modificateurs d'acc\u00e8s, en \u00e9num\u00e9rant explicitement les sous-classes autoris\u00e9es \u00e0 \u00eatre \u00e9tendues. package com.example.geometry; public sealed class Shape permits com.example.polar.Circle, com.example.quad.Rectangle, com.example.quad.simple.Square {...} <\/ul>\n