1 pièce(s) jointe(s)
La version définitive du JDK 13 est publiée avec la prise en charge d’Unicode 12.1
Java : une version à accès anticipé du JDK 13 est publiée
Oracle veut unifier les deux méthodes de la classe GraphicsEnvironment
Alors que la première release candidate du JDK 12 vient à peine d’être publiée, le JDK 13 aussi vient d'être lancé avec une version à accès anticipé. L’article précédent sur la sortie de la RC1 du JDK 12 avait annoncé qu’en plus de la version 12 du kit de développement, il y aurait encore une seconde version. Il s’agit donc du JDK 13. Après deux mois en version bêta, la RC1 du JDK 12 est parue ce 15 février. Cette version a apporté huit fonctionnalités des neuf annoncées au départ. Ces huit fonctionnalités sont les suivantes :
- Shenandoah : c’est un ramasse-miettes à faible temps de pause en effectuant le travail d’évacuation simultanée entre les threads Java en cours d’exécution. Les temps de pause sont indépendants de la taille du tas ;
- suite Microbenchmark : c’est un outil pour aider les développeurs à utiliser les microcritères existant déjà dans le code source du JDK ou en créer de nouveaux ;
- expression de commutation : apporte quelques modifications à l’instruction switch pour la rendre plus flexible ;
- API de constantes JVM : permet d’ajouter une API pour les descriptions nominales des principaux artéfacts de classes et de fichiers de classe, en particulier les constantes pouvant être chargées à partir du pool de constantes ;
- un apport AArch64, pas deux : sert à supprimer toutes les sources liées aux arm64port pour permettre à tous les contributeurs de concentrer leurs efforts sur une implémentation ARM 64 bits unique et d’éliminer le travail en double requis par la maintenance de deux ports ;
- archives CDS par défaut : sert à améliorer le processus de génération JDK afin de générer une archive CDS (Class Data Sharing) à l’aide de la liste de classe par défaut sur des plateformes 64 bits ;
- collections mélangées abandonnées pour G1 : permet d’annuler les collections d’éléments lorsqu’elles peuvent dépasser la cible de pause ;
- retournez rapidement la mémoire validée non utilisée de G1 : améliore le récupérateur G1 pour qu’il puisse renvoyer automatiquement la mémoire heap de Java au système d’exploitation lorsqu’il est inactif.
Rappelons que, la seule fonctionnalité annoncée au départ et finalement absente de cette version concerne les littéraux de chaînes bruts. Cette fonctionnalité causait quelques problèmes d’implémentation notamment le choix des délimiteurs et la mauvaise interprétation des séquences d’échappement (\n par exemple). Brian Goetz, architecte Java chez Oracle a justifié l’abandon de cette fonctionnalité en déclarant ce qui suit :
« En examinant les commentaires que nous avons reçus, je ne suis plus convaincue que nous ayons encore trouvé le bon compromis entre complexité et expressivité, ou que nous en avons suffisamment exploré l’espace de conception pour être sûr que la conception actuelle est la meilleure que nous puissions faire. En le retirant, nous pouvons continuer à affiner la conception, explorer plus d'options et viser un aperçu répondant réellement aux exigences du processus de fonction de prévisualisation (JEP 12) ».
Alors, cette fonctionnalité peut-elle réapparaître dans le JDK 13 qui sera également publié en 2019 ? Même si les fonctionnalités d’une version à accès anticipé ne peuvent pas faire l’objet d’une disponibilité générale, Oracle l’a quand même publié pour ouvrir le débat sur les propositions, et des corrections. La note de versions ne présente pas beaucoup d’informations, mais quelques constructions ont été annoncées. Dans cette note, Oracle parle d’unifier deux méthodes de la classe GraphicsEnvironment (getCenterPoint() et getMaximumWindowBounds()) qui sont apparues dans le JDK depuis sa version 1.4. Dans le JDK 13, l’implémentation de ces méthodes est unifiée pour toutes les plateformes (Linux, Mac, Windows et Alpine Linux) et :
- getCenterPoint renvoie les coordonnées du centre de l'affichage principal, pour toutes les plateformes ;
- getMaximumWindowBounds renvoie les limites des insertions d'affichage primaire, pour toutes les plateformes.
La note de version du JDK 13 n’a pas abordé pour l’instant la réinsertion des littéraux de chaînes, mais certains internautes en parlent. Les quelques autres informations disponibles sur cette version à accès anticipé du JDK 13 sont disponibles sur le site de l’OpenJDK.
Source : OpenJDK
Et vous ?
:fleche: Que pensez-vous du JDK 13 ?
:fleche: Que proposeriez-vous pour l'intégration des littéraux de chaînes dans JDK 13 éventuellement ?
:fleche: Êtes-vous pour ou contre cette unification des méthodes de la classe GraphicsEnvironment ? Pourquoi ?
Voir aussi
:fleche: 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
:fleche: Java : le JDK 12 est disponible en version bêta, il prend en charge Unicode 11 et dispose d'un nouveau format de clé privée codé x25519 et x448
:fleche: 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)
2 pièce(s) jointe(s)
JDK 13 : toutes les fonctionnalités de la prochaine version du langage Java ont été verrouillées
JDK 13 : toutes les fonctionnalités de la prochaine version du langage Java ont été verrouillées
et une RC est prévue pour le 8 août prochain
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 ?
:fleche: Que pensez-vous de cette version du langage Java ?
Voir aussi
:fleche: Java : une version à accès anticipé du JDK 13 est publiée. Oracle veut unifier les deux méthodes de la classe GraphicsEnvironment
:fleche: 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
:fleche: 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)
2 pièce(s) jointe(s)
La version définitive du JDK 13 est publiée avec la prise en charge d’Unicode 12.1
La version définitive du JDK 13 est publiée avec la prise en charge d’Unicode 12.1
et de nombreuses améliorations
La version définitive du JDK 13, la deuxième version majeure du kit de développement Java pour le compte de l’année 2019, vient d’être publiée. Comme prévu, le JDK 13 apporte cinq nouvelles fonctionnalités majeures, notamment une nouvelle implémentation de l’API de socket héritée (legacy socket API), l’amélioration du ramasse-miettes ZGC pour restituer la mémoire non allouée et l’ajout des blocs de texte. Il y a aussi dans cette version un aperçu des expressions switch et l’archivage dynamique des classes d'application à l'aide d'AppCDS dans HotSpot.
Le développement du JDK 13 a commencé plus tôt dans l’année, en même temps que la publication de la RC1 du JDK 12. Le JDK 13 est la deuxième version du kit développement Java qui est publiée cette année d’après le nouveau modèle de développement adopté par l’OpenJDK. Ce modèle prévoit deux différentes versions du JDK par an. En juillet 2019, OpenJDK a rendu publique la liste des fonctionnalités les plus importantes du JDK 13. Une release candidate (RC) a été publiée le 8 août passé et la version stable du JDK 13 a été publiée ce mardi 17 septembre.
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 (legacy socket API), l’archivage dynamique des classes, l’ajout d’un aperçu des blocs de texte, un second aperçu des expressions switch (switch expressions) et l’amélioration de ZGC (Z Garbage Collector) pour restituer au système d’exploitation la mémoire non allouée. Voyons plus en détail de quoi il s’agit dans cette nouvelle version du langage.
La réimplémentation de l’API de socket héritée (legacy socket API)
Les API java.net.Socket et java.net.ServerSocket, ainsi que leurs implémentations sous-jacentes, remontent au JDK 1.0. L'implémentation est un mélange de code Java et C traditionnels 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.
L'implémentation présente également plusieurs problèmes de concurrence qui nécessitent une refonte. Pour cela, 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.
L’archivage dynamique des classes
L'archivage dynamique des classes d'application à l'aide d'AppCDS dans HotSpot offre des avantages supplémentaires en matière de temps de démarrage par rapport à l'archive CDS par défaut. Il améliore la convivialité d'AppCDS en éliminant la nécessité pour les utilisateurs de faire des essais pour créer une liste de classes pour chaque application. Toutefois, une procédure en trois étapes est actuellement requise pour utiliser AppCDS pour une application Java. La procédure fonctionne pour les applications utilisant 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. L'archivage dynamique activé par une option de ligne de commande simplifiera l'utilisation d'AppCDS en éliminant les essais 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. À l’avenir, d’autres améliorations pourront permettre la génération automatique d'archives lors de la première exécution d'une application.
Un aperçu des blocs de texte
En Java, incorporer un extrait de code HTML, XML, SQL ou JSON dans une chaîne littérale nécessite généralement une édition importante avec des échappements et des concaténations 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. D’après l’équipe de développement du JDK 13, cette fonctionnalité n’est pas totalement stable, mais une version de prévisualisation a été fournie dans le JDK 3.
Un bloc de texte est une chaîne de caractères à plusieurs lignes qui évite d'avoir besoin de la plupart des séquences d'échappement. Un bloc de texte formate automatiquement la chaîne de caractères d'une manière prévisible et donne aux développeurs le contrôle du format. Les développeurs du JDK 13 ont cité un certain nombre d'objectifs derrière l'ajout de blocs de texte à Java. L'un des objectifs est de simplifier l'écriture des programmes Java en facilitant l'écriture des chaînes de caractères couvrant plusieurs lignes et en évitant le plus possible les séquences d'échappement.
Un deuxième objectif est d'améliorer la lisibilité des chaînes de caractères dans les programmes qui indiquent que le code écrit provient d'autres langages.
Les améliorations apportées à ZGC (Z Garbage Collector)
ZGC est un ramasse-miettes évolutif et à faible latence. Il ne renvoie pas actuellement la mémoire inutilisée au système d'exploitation, même si la mémoire n'a pas été utilisée depuis longtemps. Ce comportement n'est pas optimal pour certaines applications et certains environnements, en particulier ceux où l'empreinte mémoire est un problème, comme les conteneurs ou les environnements où une application peut rester inactive pendant longtemps et partager ou concurrencer des ressources avec d'autres applications. Mais ce comportement a été amélioré.
Des améliorations ont été apportées au ramasse-miettes ZGC (Z Garbage Collector) pour retourner la mémoire inutilisée au système d'exploitation. Lorsque l’équipe a présenté un aperçu du JDK 13 en juillet dernier, elle avait indiqué que d'autres éboueurs (ramasse-miettes ou garbage collector) de HotSpot, tels que G1 et Shenandoah, fournissent déjà 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.
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. Un aperçu a été rendu disponible dans le JDK 12, mais de nouveaux changements ont été apportés depuis cette version. 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 ». En effet, l'intention est d'étendre switch pour qu'il puisse être utilisé soit comme une instruction, soit comme une expression, de sorte que les deux formes peuvent soit utiliser la casse traditionnelle ou la nouvelle casse, avec une nouvelle instruction pour donner une valeur à partir d'une expression switch. Ces modifications simplifieront le codage quotidien et ouvriront la voie à l’utilisation du filtrage par motif dans switch.
La prise en charge d’Unicode 12.1
Cette version du JDK met à jour le support Unicode de Java vers la version 12.1 de la norme Unicode qui inclut les éléments suivants :
- java.lang.Character supporte la base de données de caractères d’Unicode 12.1, dans laquelle 12.0 ajoute 554 caractères depuis 11.0, portant le total de caractères à 137 928. Ces ajouts comprennent 4 nouveaux scripts, pour un total de 150 scripts, ainsi que 61 nouveaux caractères emoji ;
- les classes java.text.Bidi et java.text.Normalizer supportent les niveaux #9 et #15 des annexes standard Unicode (Unicode Standard Annex) de la norme Unicode 12.0 ;
- le paquet java.util.regex supporte les clusters de graphèmes étendus basés sur le niveau #29 des annexes standard Unicode (Unicode Standard Annex) de la norme Unicode 12.0.
Source : Note de version du JDK 13
Et vous ?
:fleche: Que pensez-vous du JDK 13 ?
Voir aussi
:fleche: JDK 13 : toutes les fonctionnalités de la prochaine version du langage Java ont été verrouillées et une RC est prévue pour le 8 août prochain
:fleche: Java : une version à accès anticipé du JDK 13 est publiée, Oracle veut unifier les deux méthodes de la classe GraphicsEnvironment
:fleche: 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)
:fleche: 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
:fleche: Java 12 disponible avec les expressions Switch, un nouveau récupérateur de mémoire à faible temps de pause et diverses améliorations pour G1
