URL: https://linuxfr.org/news/sortie-de-jdk-10 Title: Sortie de JDK 10 Authors: Collectif Dring, BAud, Aldoo, claudex, Davy Defaud, ZeroHeure, Lucas, Nonolapéro, Bruno Michel et olivierweb Date: 2018年03月21日T17:32:54+01:00 License: CC By-SA Tags: java, jdk10 et lwn Score: 40 Cette dépêche aura mis du temps à venir au monde, et depuis le JDK 11 — la version avec support étendu (LTS) — est sorti, mais il est encore temps de ~~troller~~\^W discuter de façon constructive de l’évolution d’un langage qui reste aujourd’hui au cœur des entreprises. C’est l’occasion de (re)voir les ajouts côté langage, les changements et retraits côté API, les évolutions de la machine virtuelle Java (JVM), la gestion du code source ; le tout documenté au travers des [JEP](https://en.wikipedia.org/wiki/JDK_Enhancement_Proposal) à la base des spécifications de Java. ---- [Notes de version](http://www.oracle.com/technetwork/java/javase/10-relnote-issues-4108729.html) [Liste des nouveautés](http://openjdk.java.net/projects/jdk/10/) ---- Côté langage ============ Un ajout : l’inférence de type pour les variables locales (JEP 286) ------------------------------------------------------------------- Il est désormais possible de déclarer des variables locales en remplaçant le type par le mot `var` afin de laisser le compilateur deviner le type : ```java // ici, le compilo comprend que edt est de type Map var edt = Map.of("lundi", "piscine", "mardi", "pétanque"); ``` Ainsi, Java s’aligne sur de nombreux autres langages (sur la JVM, notamment Scala et Kotlin). Ce changement devrait inciter à éviter d’écrire des lignes à rallonge dont le seul but est d’éviter d’écrire les types des résultats intermédiaires. En effet, certains types peuvent être soit inconnus du programmeur (qui a la flemme d’ouvrir la Javadoc), soit très longs à écrire (types génériques), voire impossibles à écrire comme les types non dénotables, par exemple pour une classe anonyme : ```java var x = new Object() { int a; }; x.a = 42; ``` Remarque : `var` n’est pas un mot-clé, mais un identifiant de type réservé. Ainsi, il est toujours possible de déclarer une variable ou une méthode de nom `var`... mais pas une classe ! Côté API ======== Changements ----------- ### JEP 314 On parle ici d’une amélioration sensible de l’internationalisation en s’appuyant sur des extensions d’Unicode. Voici la liste des nouvelles venues : - `cu` (type de devise, « _currency type_») ; - `fw` (premier jour de la semaine, « _first day of week_ ») ; - `rg` (_region override_) ; - `tz` (_time zone_). Tout ça va permettre aux classes de formatage (`java.text.DateFormat`, `java.text.NumberFormat`...) de récupérer directement les informations Unicode disponibles. Suppressions (API obsolètes) ---------------------------- Suppression de l’attribut `java.lang.SecurityManager.inCheck`. Suppression des méthodes suivantes : - `java.lang.Runtime.getLocalizedInputStream(java.io.InputStream)` ; - `java.lang.Runtime.getLocalizedOutputStream(java.io.OutputStream)` ; - `java.lang.SecurityManager.classDepth(java.lang.String)` ; - `java.lang.SecurityManager.classLoaderDepth()` ; - `java.lang.SecurityManager.currentClassLoader()` ; - `java.lang.SecurityManager.currentLoadedClass()` ; - `java.lang.SecurityManager.getInCheck()` ; - `java.lang.SecurityManager.inClass(java.lang.String)` ; - `java.lang.SecurityManager.inClassLoader()`. Côté JVM ======== JEP 304 ------- Le ramasse‐miettes (_garbage collector_) est désormais défini par une interface plus propre, permettant dans le futur d’ajouter ou retirer plus facilement des implémentations de ramasse‐miettes. À noter que, dans cette version, les auteurs se sont contentés de faciliter ce travail, sans le mettre en œuvre. JEP 307 ------- Le ramasse‐miettes par défaut (nommé « G1 » et promu à ce poste dans le JDK 9) est amélioré pour limiter les cas de latence, et ainsi limiter les impacts de la version précédente pour les utilisateurs. JEP 310 ------- La mémoire consommée par des processus java est réduite en améliorant le partage de méta‐données. Cela a également un effet positif sur la vitesse de démarrage, avec des objectifs ambitieux : des lancements jusqu’à 20 à 30 % plus rapides, et une économie de 340 Mio sur des processus consommant 13 Gio. À noter que ce dernier chiffre concerne un cas de serveur d’applications faisant tourner six JVM. JEP 312 ------- Pas mal d’actions émises par la JVM imposent aujourd’hui un arrêt de tous les fils d’exécution (_threads_) en cours. Cette JEP permet à la JVM d’arrêter un ou plusieurs fils d’exécution spécifiques, sans tout stopper. Pour se figurer l’impact, il faut se dire qu’aujourd’hui la capture d’une pile d’appel complète — lors de l’interception d’une exception — imposait ce type de blocage complet. Désormais, seul un fil d’exécution sera interrompu, permettant au reste de l’application de continuer joyeusement sa route. On va donc vers une réduction générale de la latence. JEP 316 ------- L’idée ici est d’utiliser les nouvelles mémoires économiques de type NV-DIMM en permettant à l’utilisateur de spécifier son choix. Cela se fait, bien sûr non pas dans le code, mais dans les arguments de la JVM, sous la forme : `-XX:AllocateHeapAt=`. En effet, ces mémoires sont typiquement accessibles via le système de fichiers, que ce soit sous [Windows](https://channel9.msdn.com/events/build/2016/p470) ou [GNU/Linux](https://lwn.net/Articles/618064). JEP 317 ------- Graal, un nouveau compilateur à la volée (JIT — _Just In Time_ — en anglais) introduit dans le JDK 9 est désormais activable via des options de la ligne de commande, que voici : ~~~ -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler ~~~ Rien de réellement nouveau, mais cela va permettre d’avoir plus de testeurs (et donc d’améliorer la qualité). Côté code ========= JEP 296 ------- Le code source de Java, jusqu’ici réparti dans huit dépôts Mercurial séparés, est regroupé au sein d’un dépôt unique. Pour les évolutions ou corrections qui touchent plusieurs composants (par exemple « jdk » et « langtools »), cela permettra d’avoir un seul _commit_ atomique. Cela est cohérent, sachant que tous les composants suivaient le même cycle de vie de toute façon. JEP 313 ------- Un peu de nettoyage avec le retrait de l’outil _javah_, qui n’était de toute façon plus utilisé depuis le JDK 9 et affichait des avertissements lorsqu’on l’invoquait. En charge de la génération de fichiers natifs d’en‐tête, cette fonction avait déjà été réimplémentée directement dans _javac_ depuis le JDK 8. JEP 322 ------- La numérotation des versions Java change ! On passe donc de : ~~~ openjdk version "1.8.0_161" OpenJDK Runtime Environment (build 1.8.0_161-b14) OpenJDK 64-Bit Server VM (build 25.161-b14, mixed mode) ~~~ À ceci (pour l’exemple, on imagine un _build_ 42 d’un JDK 11 LTS) : ~~~ openjdk 11 2018年09月20日 LTS OpenJDK Runtime Environment (build 11+42-LTS) OpenJDK 64-Bit Server VM (build 11+42-LTS, mixed mode) ~~~ Changement _a priori_ cosmétique, mais qui pourrait avoir de lourdes conséquences... L’avenir répondra à cette question. En effet, beaucoup d’éditeurs de logiciels, font des tests assez fins sur les versions pour s’assurer que tel ou tel bogue ne risque pas de les affecter. Pour les lecteurs de la Javadoc du JRE, l’étiquette `@since` reste alignée avec la propriété système `java.specification.version`. Et pour l’occasion, deux nouvelles propriétés sont ajoutées : * `java.version.date`, qui fournit la date de disponibilité de cette version ; * `java.vendor.version`, optionnelle, pour la version spécifique d’un correctif de distribution GNU/Linux par exemple. JEP 319 ------- Jusqu’ici, le jeu de certificats déclaré dans le JDK était par défaut vide, obligeant un développeur à les rajouter. Désormais, un certain nombre d’autorités sont intégrées, dont notamment : * Let’s encrypt ; * Digicert ; * Comodo ; * et quelques autres.

AltStyle によって変換されたページ (->オリジナル) /