OpenJDK a rendu disponible une liste des fonctionnalités majeures qui ont été prévues pour apparaître dans la prochaine version du JDK, et donc la nouvelle version du langage Java. En tout, OpenJDK a présenté cinq nouvelles fonctionnalités, notamment une nouvelle implémentation de l’API de socket héritée, l’amélioration du ramasse-miettes ZGC pour restituer la mémoire non utilisée au système d’exploitation et l’ajout des blocs de textes. Il s’agit en effet d’une version de prévisualisation qui a été publiée. Une release candidate (RC) a été prévue le 8 août prochain avant la publication de la version stable le 17 septembre.La construction du JDK 13, la deuxième version majeure du JDK de cette année selon le nouveau calendrier de publication l’OpenJDK, est enfin terminée et les nouvelles fonctionnalités ont été rendues disponibles pour la communauté. Cette version du JDK introduit cinq nouvelles fonctionnalités pour le langage. On a, en général, la réimplémentation de l’API de socket héritée, l’archivage dynamique des classes, l’ajout des blocs de textes, les expressions de commutation (switch expression) et l’amélioration de ZGC (Z Garbage Collector) pour restituer au système d’exploitation la mémoire non allouée. Voyons en détail de quoi il s’agit dans cette nouvelle version du langage.
ZGC (Z Garbage Collector) a été amélioré
En effet, ZGC ne se désengage pas actuellement et ne restitue pas de la mémoire au système d'exploitation, même si cette mémoire était inutilisée depuis longtemps. Ce comportement n'est pas optimal pour tous les types d'applications et d'environnements, en particulier ceux où l'encombrement de la mémoire est une préoccupation. On a par exemple les conteneurs ou les environnements dans lesquels une application peut rester inactive pendant longtemps et partager des ressources avec d'autres applications ou faire la concurrence pour des ressources, etc. La fonctionnalité a été améliorée par l’équipe du JDK 13 pour permettre de restituer la mémoire non allouée au système d’exploitation.
Aussi, l’équipe du JDK a précisé que d'autres éboueurs (ramasse-miettes ou garbage collector) de HotSpot, tels que G1 et Shenandoah, fournissent aujourd'hui cette capacité, que certaines catégories d'utilisateurs ont trouvée très utile. De cette manière, l'ajout de cette capacité à ZGC pourrait également être bien accueilli par le même groupe d'utilisateurs.
La réimplémentation de l’API de socket hérité
Selon les explications fournies sur le sujet, les API java.net.Socket et java.net.ServerSocket, ainsi que leurs implémentations sous-jacentes, remontent à JDK 1.0. L'implémentation est un mélange de code Java et C traditionnel qui est difficile à maintenir et à déboguer. L'implémentation utilise la pile de threads comme tampon d'E/S, une approche qui a nécessité d'augmenter à plusieurs reprises la taille de la pile de threads par défaut. L'implémentation utilise une structure de données native pour prendre en charge la fermeture asynchrone, source de fiabilité subtile et de problèmes de portage au fil des ans. L'implémentation présente également plusieurs problèmes de concurrence qui nécessitent une refonte.
Dans le JDK 13, l'implémentation sous-jacente pour les API java.net.Socket et java.net.ServerSocket a été remplacée par une implémentation plus simple, plus moderne, plus facile à gérer et plus facile à déboguer. La nouvelle implémentation sera facile à adapter pour fonctionner avec des threads en mode utilisateur, également appelés fibres. Vous pouvez en savoir plus grâce à la note de version du JDK 13 fournie à cet effet.
Un deuxième aperçu des expressions switch
Les expressions switch ont été proposées pour la première fois en décembre 2017 par le JEP 325. Elles ont été ciblées sur le JDK 12 en août 2018 à titre de prévisualisation. Des commentaires ont d'abord été sollicités sur la conception de la fonctionnalité, puis sur l'utilisation des expressions switch et de l'instruction switch améliorée. La conception actuelle de l'instruction switch en Java suit de près celle des langages tels que C et C++ et prend en charge le traitement par défaut de la sémantique. Ce flux de contrôle traditionnel est souvent utile pour l'écriture de code de bas niveau (comme les analyseurs syntaxiques pour les codages binaires), comme switch dans les contextes de niveau supérieur.
Cependant, l’équipe du JDK estime que sa nature sujette aux erreurs commence à l'emporter sur sa flexibilité. Ainsi, sur la base de ces informations, le JDK 13 apporte une modification à la fonctionnalité pour générer une valeur à partir d'une expression switch. L’instruction « break with value » est supprimée au profit d'une nouvelle instruction « yield ». Ces modifications simplifieront le codage quotidien et ouvriront la voie à l’utilisation du filtrage par motif (JEP 305) dans switch. Ceci est une fonctionnalité de prévisualisation dans JDK 13.
Les archives dynamiques du CDS
L'archivage des classes d'application à l'aide d'AppCDS dans HotSpot offre des avantages supplémentaires en matière de temps de démarrage et de mémoire par rapport à l'archive CDS par défaut. Toutefois, une procédure en trois étapes est actuellement requise pour utiliser AppCDS pour une application Java : faire un ou plusieurs essais pour créer une liste de classe, ensuite vider une archive en utilisant la liste de classes créée et courir avec les archives. De plus, l’équipe JDK a expliqué que cette procédure ne fonctionne que pour les applications qui utilisent uniquement des chargeurs de classes intégrés.
Il existe un autre support expérimental pour l'archivage des classes dans HotSpot, mais son utilisation n'est pas facile. À ce titre, l'archivage dynamique activé par une option de ligne de commande simplifiera l'utilisation d'AppCDS en éliminant les essais (étape 1 ci-dessus) et prendra en charge les chargeurs de classes intégrés et les chargeurs de classes définis par l'utilisateur de manière efficace et uniforme. D’autres améliorations consécutives pourront permettre la génération automatique d'archives lors de la première exécution d'une application.
Cela éliminerait l'étape de création explicite d'archives. L'utilisation de CDS/AppCDS pourrait alors être complètement transparente et automatique. Ainsi, dans le JDK 13, le partage des données de classe d'application a été réalisé pour permettre l'archivage dynamique des classes à la fin de l'exécution de l'application Java. Les classes archivées incluront toutes les classes d'application et les classes de bibliothèque chargées qui ne figurent pas dans l'archive CDS par défaut de la couche de base.
Un aperçu des blocs de texte
En Java, incorporer un extrait de code HTML, XML, SQL ou JSON dans un littéral de chaîne "..." nécessite généralement une édition importante avec échappements et concaténation avant que le code contenant l'extrait ne soit compilé. Le fragment est souvent difficile à lire et difficile à maintenir. Cela ne devrait plus être le cas avec les blocs de texte. Un bloc de texte est un littéral de chaîne multiligne qui permet d’éviter le recours à la plupart des séquences d'échappement. Il formate automatiquement la chaîne de manière prévisible et donne au développeur le contrôle du format s'il le souhaite. D’après l’équipe, cette fonctionnalité est encore au stade de prévisualisation dans le JDK 13.
Source : OpenJDK
Et vous ?
Que pensez-vous de cette version du langage Java ?Voir aussi
Java : une version à accès anticipé du JDK 13 est publiée. Oracle veut unifier les deux méthodes de la classe GraphicsEnvironment Java : Oracle publie la première release candidate du JDK 12 avec toutes les fonctionnalités majeures annoncées sauf les littéraux de chaînes bruts Les littéraux de chaîne bruts ont été supprimés de Java 12 comme l'a suggéré la proposition d'amélioration JDK (JEP) 
Envoyé par Gugelhupf
