Sortie de JDK 10

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 au coeur des entreprises aujourd’hui.

C’est l’occasion de (re)voir les ajouts côté langage, les changements et retraits côté API, les évolutions de la JVM, la gstion du code source, le tout documenté au travers des JEP à la base des spécifications de Java.

Sommaire

Côté langage

Un ajout : l’inférence de type pour les variables locales (JEP286)

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 :

// ici, le compilo comprend que edt est de type Map<String, String>
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 :

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

JEP314

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 formattage (java.text.DateFormat, java.text.NumberFormat…) de récupérer directement les informations Unicode disponibles.

Suppressions (API obsolètes)

Suppression de l’attribut suivant : 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

JEP304

Le 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.

JEP307

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.

JEP310

La mémoire consommée par des process 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 rapide, et une économie de 340 Mo sur des processus consommant 13 Go. A noter que ce dernier chiffre concerne un cas de serveur d’applications faisant tourner 6 JVM .

JEP312

Pas mal d’actions émises par la JVM imposent aujourd’hui un arrêt de tous les threads en cours d’exécution. Cette JEP permet à la JVM d’arrêter une ou plusieurs threads 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, seule une thread sera interrompue, permettant au reste de l’application de continuer joyeusement sa route.

On va donc vers une réduction générale de la latence.

JEP316

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=<path>

En effet, ces mémoires sont typiquement accessibles via le système de fichier que ce soit sous Windows ou Linux.

JEP317

Graal, un nouveau compilateur juste-à-temps (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

JEP296

Le code source de Java, jusqu’ici réparti dans 8 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.

JEP313

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’entête, cette fonction avait déjà été ré-implémentée directement dans javac depuis le JDK 8.

JEP322

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. Beaucoup d’éditeurs logiciels, en effet, font des tests assez fins sur les versions pour s’assurer que tel ou tel bug ne risque pas de les affecter.

Pour les lecteurs de la javadoc du JRE, le tag @since reste aligné 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 patch de distribution Linux par exemple

JEP319

Jusqu’ici le jeu de certificats déclarés 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, et entre autres :

  • Let’s encrypt
  • Digicert
  • Comodo
  • et quelques autres.

Commentaires :
voir le flux atom
ouvrir dans le navigateur

(Source: LinuxFr.org : les dépêches)
Logo