1 pièce(s) jointe(s)
Java : le JDK 12 est disponible, il prend en charge Unicode 11 et les expressions Switch
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
Oracle a rendu disponible une version expérimentale du JDK 12 sur les plateformes Linux, Windows et MacOS pour tester les nouvelles fonctionnalités apportées et les améliorer en cas de besoin avant la date de sortie générale qui est prévue pour le 19 mars 2019. En septembre 2017, Oracle annonçait qu’il y aura à l’avenir deux versions du JDK par an du fait que Java soit en concurrence directe avec d’autres plateformes qui sont mises à jour plus souvent. La firme a tenu parole puisque après avoir lancé, il y a quelques mois environ, la version 11 de sa plateforme Java SE, le JDK 12 vient d’être présenté en bêta test.
Rappelons que la plateforme Java SE est composée de JSR (définissant les spécifications de Java), JDK (comprenant les bibliothèques logicielles de Java), JRE (l’environnement d’exécution de Java également inclus dans JDK) et intègre des améliorations techniques avec les nouvelles fonctionnalités telles que la prise en charge d’une nouvelle forme de pool de constante CONSTANT_Dynamic, le mot clé var pour la déclaration des paramètres formels d’une expression typée implicitement et un “gabage collector” ou ramasse-miettes Epsilon pour générer l’allocation de mémoire sans implémenter de mécanismes de récupération de mémoire.
Le JDK 12 est présenté comme une implémentation de référence de la version 12 de la plateforme Java SE. Il est caractérisé par neuf nouveautés et de nouvelles fonctionnalités telles que la prise en charge de Unicode 11 donc plus amélioré que le JDK 11 (qui prend en charge Unicode 10), l’annulation de la valeur par défaut keytool-keyalg, un nouveau format de clé privée codé x25519 et x448 compatible avec la norme RFC 8410. On compte en tout neuf caractéristiques essentiels du JDK 12 :
- 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 micro-critè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 ;
- littéraux de chaînes bruts : permet aux développeurs de créer leurs propres littéraux et de les ajouter au langage ;
- 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.
Il intègre également des nouveaux apports et des modifications majeures comme un nouvel indicateur de ligne de commande pour un rapport d’erreur plus étendu dans les journaux d’incidents, la propriété système user.timezone a été modifiée et peut maintenant renvoyer une valeur null selon sa configuration ou encore de nouvelles options d’interdiction et d’autorisation pour la propriété système java.security.manager et bien d’autres.
Oracle a pris la peine de décrire chaque fonctionnalité pris en compte par le JDK 12 et notifie cependant que ce dernier ne prend pas encore en compte le formatage de nombre compact. Il faut savoir que le formatage de nombre compact fait référence à la représentation d’un nombre sous une forme courte ou lisible par l’homme.
Il encourage les développeurs à tester le l’outil et à faire part de leurs commentaires et suggestions par rapport à d’éventuels problèmes ou bugs rencontrés afin d’aider à le peaufiner et a mis à la disposition de la communauté une page dédiée qui présente les résultats des tests toutes les semaines.
Source : JDK 12, Note de version
Et vous ?
:fleche: Êtes-vous un développeur Java ? Que pensez-vous de ces fonctionnalités de la version bêta du JDK 12 ?
:fleche: L'avez-vous déjà testé ? Partagez avec nous vos impressions
Voir aussi
:fleche: Andrew Haley de Red Hat donne son avis sur l'avenir d'OpenJDK, l'implémentation libre de Java SE, après la sortie de JDK 11 sous licence commerciale
:fleche: JDK 11 : trois nouveautés sont prévues ainsi que la suppression de JAVA EE, JavaFX et CORBA, dans le cadre des mises à jour semestrielles
:fleche: JDK 10 : les fonctionnalités de la prochaine version de Java sont désormais gelées, la sortie est attendue pour le 20 mars 2018
:fleche: Java 8 ne va plus recevoir de mises à jour et correctifs de sécurité à partir de septembre à moins de passer à un support commercial
1 pièce(s) jointe(s)
Java 12 ne prendra probablement pas en charge les littéraux de chaîne bruts
Java 12 ne prendra probablement pas en charge les littéraux de chaîne bruts
la proposition d'amélioration JDK (JEP) suggère qu'on les supprime
Les tests pour finaliser la sortie originale du JDK 12 de Java en janvier prochain continuent depuis la disponibilité de la version bêta. Comme rapporté le mardi dernier, cette version bêta est caractérisée par neuf nouveauté essentielles et quelques nouvelles fonctionnalités. Le JDK 12 prend en charge Unicode 11, un nouveau format de clé privée codé x25519 et x448 compatible avec la norme RFC 8410 etc… L’une des principales caractéristiques de cette version est la prise en charge des littéraux de chaînes bruts. Les littéraux de chaînes de caractères permettent au développeur de créer leurs propres littéraux et de les ajouter au langage. L’ajout de cette fonctionnalité dans le langage s’est fait aussi dans le but d’aider les développeurs à exprimer plus facilement des séquences de caractères, à fournir des chaînes ciblées pour les grammaires, et à couvrir plusieurs lignes de sources. Toutefois, la proposition d'amélioration JDK (JEP), un processus élaboré par Oracle Corporation pour collecter des propositions d'amélioration du kit de développement Java et d'OpenJDK, vient de proposer qu’on supprime ces littéraux de la nouvelle version de JDK 12.
La JEP donne plusieurs raisons à cette proposition de suppression. La plupart de ces raisons se basent principalement sur des commentaires reçus qui ressortent quelques limites de cette fonctionnalité. « 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) », écrit dans un mail, Brian Goetz, architecte de langage Java chez Oracle.
Dans le mail adressé à la communauté, il expose quelques-uns de ces commentaires qui « sont sont incomplets et sans ordre particulier » :
- la séquence à deux guillemets ‘’ peut être confondue pour une chaîne vide mais en fait c’est un délimiteur ;
- bien que ce soit cool que nous puissions intégrer une série de dix-sept devis dans une chaîne de caractères entre dix-huit guillemets, ces chaînes peuvent également être difficiles à lire ;
- il n’y pas de voie directe pour démarrer ou de terminer un littéral de chaîne brute avec un backquote ;
- les littéraux de chaîne brute peuvent être multilignes mais les chaînes traditionnelles de littéraux ne peuvent pas l'être. Alternativement, les littéraux multilignes doivent aussi être brut, ce qui ne correspond pas toujours à ce que l’utilisateur veut. C’est un inutile asymétrie, étant donné que ces propriétés sont logiquement indépendantes, et ces asymétries augmentent généralement la charge cognitive de l'utilisateur ;
- le caractère backquote est un peu léger ; il est facile à manquer et peut donc semer la confusion lorsque la chaîne se termine et le code le contenant reprend ;
- la règle "nombre illimité de guillemets" peut contraindre les IDE sur le point de savoir si une séquence de guillemets est open-contents-close, ou un grand séparateur d'ouverture, limiter leur capacité à aider en remplissant les délimiteurs de fermeture et placer le curseur au bon endroit. Nous voulons que Java reste conviviales.
A ce dernier commentaire, un internaute répond suivant ces lignes « honnêtement, cela me semble être un argument insensé. Les littéraux de chaîne bruts fonctionnent déjà assez bien dans IntelliJ, avec la surbrillance et tout. Visual Studio Code pourrait être facilement modifié pour prendre cela en charge, en prenant en compte des schémas similaires d'autres langages de programmation déjà pris en charge, en particulier Markdown. Les surligneurs basés sur des expressions régulières pourraient très facilement prendre en charge cette syntaxe en utilisant des références arrière. Et quand tout le reste échoue, les expressions comme hardcoding `, ``, ```, ```` ne semble pas être la plus mauvaise façon de le faire en Java ».
Un autre, estime qu’il ne voit pas pourquoi l’on se pose beaucoup de questions sur une chose qui paraît assez simple. Il propose, pour palier au problème des littéraux, de copier purement et simplement l’implémentation d’un autre langage pour clore le débat. Brian Goetz, toujours dans son mail, pense que laisser la chose dans l’état actuel ne va pas dans l’avantage au langage et qu’il faudra attendre peut-être un plus pour intégrer cette fonctionnalité de façon permanente. Il finit son mail en déclarant que « nous pensons pouvoir faire mieux sur certains ou plusieurs de ces fronts. L'un des avantages de la nouvelle cadence plus rapide est que le coût de rater un train (même celui auquel vous êtes déjà monté, mais qui n'a pas encore quitté la gare) est beaucoup plus bas. Et, en supposant qu'il soit peu probable que nous quittions Preview sans modification, retirer maintenant ne modifie pas la date probable à laquelle cette fonctionnalité deviendra permanente, car nous voudrions probablement reprévisualiser une version modifiée de toute façon ».
Doit-on s’attendre à voir cette fonctionnalité à la date de sortie définitive ou sera-t-elle retiré pour cette version du langage ? Pour l’instant rien n’est encore décidé et les tests pour rendre la version stable se poursuivent.
Source : Brian Goetz
Et vous ?
:fleche: Qu'en pensez-vous ?
:fleche: Selon vous, les littéraux devrait-ils être supprimés de JDK 12 ? Pourquoi ?
Voir aussi
: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: Andrew Haley de Red Hat donne son avis sur l'avenir d'OpenJDK, l'implémentation libre de Java SE, après la sortie de JDK 11 sous licence commerciale
:fleche: JDK 11 : trois nouveautés sont prévues ainsi que la suppression de JAVA EE, JavaFX et CORBA, dans le cadre des mises à jour semestrielles
:fleche: JDK 10 : les fonctionnalités de la prochaine version de Java sont désormais gelées, la sortie est attendue pour le 20 mars 2018
:fleche: Java 8 ne va plus recevoir de mises à jour et correctifs de sécurité à partir de septembre à moins de passer à un support commercial
Les littéraux de chaîne bruts ont été supprimés de Java 12
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)
Dans la deuxième semaine de ce mois, Oracle avait lancé la version bêta du JDK 12 sur les plateformes Linux, Windows et MacOS pour tester les nouvelles fonctionnalités apportées et les améliorer en cas de besoin avant la date de sortie générale qui est prévue pour le 19 mars 2019. Le JDK est caractérisé par neuf nouveautés essentielles. Il apporte de nouvelles fonctionnalités telles que la prise en charge d'Unicode 11, donc plus amélioré que le JDK 11 (qui prend en charge Unicode 10), l’annulation de la valeur par défaut keytool-keyalg, un nouveau format de clé privée codé x25519 et x448 compatible avec la norme RFC 8410. L’une des principales caractéristiques de cette version du JDK est la prise en charge des littéraux de chaînes bruts.
Les littéraux de chaînes de caractères permettent au développeur de créer leurs propres littéraux et de les ajouter au langage. L’ajout de cette fonctionnalité dans le langage s’est fait aussi dans le but d’aider les développeurs à exprimer plus facilement des séquences de caractères, à fournir des chaînes ciblées pour les grammaires, et à couvrir plusieurs lignes de sources. Par la suite, l’équipe de propositions d'amélioration du JDK (JEP), le processus permettant à Oracle Corporation de collecter des propositions d'amélioration du kit de développement Java et du OpenJDK, a proposé qu’on supprime ces littéraux de la nouvelle version du JDK.
La JEP ajoute comme information qu’un littéral de chaîne brut est constitué d'un ou de plusieurs caractères enfermés dans des séquences de pics de contrôle (\u0060, citation arrière , accent grave). Un littéral de chaîne brut s'ouvre avec une séquence d'un ou plusieurs backticks. Le littéral de chaîne brut se ferme quand une séquence de pièces jointes de longueur égale est rencontrée lorsqu’elle a été ouverte avec le littéral de chaîne brut. Toute autre séquence de contrecoups est traitée comme faisant partie du corps de la chaîne. Le PEC a fourni plusieurs raisons à cette proposition de suppression, la majorité sur basés principalement sur des commentaires reçus qui ressortent quelques limites de cette fonctionnalité.
Brian Goetz, architecte de langage Java chez Oracle a tenu à apporter quelques clarifications à cette proposition : « 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) », avait-il écrit dans un mail adressé à la communauté.
Selon les récentes explications données par la JEP, on peut noter qu’un littéral de chaîne brut peut s’étendre sur plusieurs lignes et n'interprète pas les séquences d'échappement telles que les \n correspondant aux échappements Unicode de la forme \uXXXX ou que les littéraux de chaîne bruts en général ne prennent pas directement en charge l'interpolation de chaîne. Voici un exemple de littéral de chaîne brut sur multiligne :
Code:
1
2
3
4
5
6
7
|
String html = `<html>
<body>
<p>Hello World.</p>
</body>
</html>
`; |
La JEP souligne que les caractères d'échappement d’un littéral de chaîne brut ne sont jamais interprétés à l'exception de CR et CRLF, qui sont des terminateurs de ligne spécifiques à la plate-forme. Les séquences CR ( \u000D) et CRLF ( \u000D\u000A) sont toujours traduites en LF ( \u000A). Cette traduction fournit le comportement le moins surprenant sur toutes les plateformes.
« Les littéraux de chaîne traditionnels prennent en charge deux types d'échappement : les échappements Unicode de la forme \uxxxx et les séquences d’échappement telles que \n. Aucun type d'échappement n'est traité dans les littéraux de chaîne bruts ; les caractères individuels qui composent l'échappement sont utilisés tels quels. Cela implique que le traitement des échappements Unicode est désactivé lorsque le lexer (encore appelé analyseur lexical, c'est un programme réalisant une analyse lexicale) rencontre un backtick d'ouverture et réactivé lorsqu'il rencontre un backtick de fermeture. Par souci de cohérence, l’échappement Unicode ne peut pas être utilisé comme substitut du backtick d’ouverture », a déclaré la JEP et donne des exemples de littéraux de chaînes bruts correspondant à cette déclaration :
Code:
1
2
3
4
5
6
7
8
|
`"` // a string containing " alone
``can`t`` // a string containing 'c', 'a', 'n', '`' and 't'
`This is a string` // a string containing 16 characters
`\n` // a string containing '\' and 'n'
`\u2022` // a string containing '\', 'u', '2', '0', '2' and '2'
`This is a
two-line string` // a single string constant |
Selon la JEP, ce serait une erreur de compilation d'avoir une séquence de backtick ouverte et aucune séquence de backtick proche correspondante avant la fin de l'unité de compilation. Un autre problème lié aux littéraux de chaîne bruts est la gestion des marges. En effet, il est difficile de savoir si la chaîne doit être formatée dans la marge de (gauche comme dans herodoc), ou idéalement, mélangée avec l’indentation utilisée par le code environnant. L’équipe compare cela à une indentation accidentelle. Par exemple, certains développeurs peuvent choisir de coder comme ceci :
Code:
1
2
3
4
5
|
String s = `
this is my
embedded string
`; |
tandis que d'autres développeurs peuvent ne pas aimer le style en retrait et choisir d'intégrer par rapport à l'indentation du code comme ceci :
Code:
1
2
3
4
5
|
String html = `
this is my
embedded string
`; |
Il existe d’autres problèmes liés aux littéraux de chaîne bruts (par exemple les délimiteurs) présentés par la JEP sur le site du OpenJDK ainsi que certaines alternatives proposées à certains de ces problèmes. Par comparaison à ses pairs, la JEP estime que les langages de programmation tels que C++, Groovy, JavaScript, Python pour ne citer que ceux-là utilisent des littéraux de chaîne bruts. L’équipe dit qu'elle étudie ces langages pour les délimiteurs qu’ils utilisent ou pour rechercher des représentations de chaînes.
Un internaute conseille à la JEP de regarder dans Python 3.7 pour en tricher l’implémentation des littéraux de chaîne bruts qu’ils jugent être une réussite. « En fait, je craignais que Java ne soit trop influencé par C# en ce qui concerne les chaînes. Les développeurs Java devraient regarder dans python 3.7 et non pas C# pour de belles syntaxes de chaînes », estime-il.
Un autre par contre dit ne trouver aucun des arguments fournis par la JEP assez convaincant et juge inutile une telle fonctionnalité. « En termes simples, je ne vois que très peu de cas d’utilisation où les chaînes brutes pourraient être utiles, qui permettent et / ou encouragent de nombreuses mauvaises pratiques. Dans mon esprit, les chaînes multilignes sont encore moins utiles et ajoutent une complexité inutile (voir la section sur la gestion des marges). Je ne pense pas que ça vaille le coup », commente-il. La JEP indique cependant, que dans l’objectif de vouloir remplacer les littéraux de chaîne traditionnels par les littéraux de chaîne bruts dans une version future, l’équipe continue de travailler dessus.
Source : OpenJDK
Et vous ?
:fleche: Qu'en pensez-vous ?
Voir aussi
: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: Java 12 ne prendra probablement pas en charge les littéraux de chaîne bruts, la proposition d'amélioration JDK (JEP) suggère qu'on les supprime
:fleche: Andrew Haley de Red Hat donne son avis sur l'avenir d'OpenJDK, l'implémentation libre de Java SE, après la sortie de JDK 11 sous licence commerciale
:fleche: JDK 11 : trois nouveautés sont prévues ainsi que la suppression de JAVA EE, JavaFX et CORBA, dans le cadre des mises à jour semestrielles
:fleche: JDK 10 : les fonctionnalités de la prochaine version de Java sont désormais gelées, la sortie est attendue pour le 20 mars 2018
1 pièce(s) jointe(s)
Java : Oracle publie la première release candidate du JDK 12
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
L’annonce a été faite le 15 février par Oracle que la première version Release Candidate du JDK 12 est disponible en téléchargement pour les plateformes Linux, Mac OS et Windows. Cette version RC1 a été lancée, dit la JEP (proposition d’amélioration du JDK), dans le but de recenser les bogues qu’il pourrait y avoir ainsi que les différentes suggestions de la communauté avant sa date de disponibilité générale prévue pour le 19 mars prochain. Passons en revue sa feuille de route depuis l’annonce de sa version bêta en décembre à ce jour.
La publication de la version bêta du JDK 12 remonte à décembre dernier. À ce moment, plusieurs fonctionnalités sont apparues dans le kit de développement et plusieurs autres ont été annoncées pour la suite de sa mise au point. Cette version bêta alignait neuf nouveautés principales et quelques fonctionnalités telles que la prise en charge d'Unicode 11, un nouveau format de clé privée codée x25519 et x448 compatible avec la norme RFC 8410. Les neuf caractéristiques qui ont été présentées 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 ;
- littéraux de chaînes bruts : permettent aux développeurs de pouvoir utiliser des chaînes littérales brutes sans échappement ;
- 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.
Seulement quelques jours après cette publication, la JEP annonçait qu’une des fonctionnalités mises en avant dans la version bêta ne sera probablement plus prise en charge ou ne sera plus intégrée dans le JDK 12. Il s’agissait des littéraux de chaînes bruts pour lesquels la JEP a indiqué n’avoir pas encore trouvé le bon moyen d’implémenter cette fonctionnalité au sein du JDK 12.
« 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) », avait écrit dans un mail, Brian Goetz, architecte du langage Java chez Oracle.
La JEP a mis en exécution cette annonce plus tard, vers la fin du mois de décembre, en supprimant définitivement cette fonctionnalité de la préversion du JDK 12. Pour se justifier, la JEP avait listé plusieurs raisons à cette suppression. On pourrait citer par exemple le fait que les littéraux de chaîne peuvent s’étendre sur plusieurs lignes et n'interprète pas les séquences d'échappement telles que les \n correspondant aux échappements Unicode de la forme \uXXXX ou le fait que les littéraux de chaînes bruts en général ne prennent pas directement en charge l'interpolation de chaîne. De nombreux autres problèmes (par exemple les délimiteurs) liés aux littéraux de chaînes bruts avaient été cités par la JEP sur le site du OpenJDK.
Par comparaison à ses pairs, la JEP indiquait que les langages de programmation tels que C++, Groovy, JavaScript, Python pour ne citer que ceux-là utilisent des littéraux de chaîne bruts et donc, qu'elle étudie ces langages pour les délimiteurs qu’ils utilisent ou pour rechercher des représentations de chaînes. Un groupe d’internautes avaient conseillé à la JEP de regarder dans Python 3.7 pour en tricher l’implémentation des littéraux de chaînes bruts qu’ils jugent être une réussite. « En fait, je craignais que Java ne soit trop influencé par C# en ce qui concerne les chaînes. Les développeurs Java devraient regarder dans Python 3.7 et non pas C# pour de belles syntaxes de chaînes », avait-il écrit en commentaire.
D’autres par contre, étaient un peu catégoriques sur le sujet. Un parmi eux avait écrit ceci : « En termes simples, je ne vois que très peu de cas d’utilisation où les chaînes brutes pourraient être utiles, qui permettent ou encouragent de nombreuses mauvaises pratiques. Dans mon esprit, les chaînes multilignes sont encore moins utiles et ajoutent une complexité inutile (voir la section sur la gestion des marges). Je ne pense pas que ça vaille le coup ».
De nombreux tests étant faits depuis décembre passé, la RC1 vient donc d’être publiée. Elle est publiée avec les 8 fonctionnalités majeures restantes depuis la suppression des littéraux de chaînes bruts. Ce sont : Shenandoah (le ramasse-miettes à temps de pause réduit), l’API de constantes JVM, la suite Microbenchmark, l’annulation des collections mixtes pour G1, le retour rapide de la mémoire non utilisée de G1, les archives CDS par défaut, un apport AArch64 et les expressions de commutation. Toutes les fonctionnalités sont donc au rendez-vous à part bien sûr les littéraux de chaînes bruts. Vous pouvez accéder au site de l’OpenJDK pour en apprendre davantage sur cette release candidate du JDK 12 et en savoir plus sur les fonctionnalités précitées.
En septembre 2017, Oracle avait annoncé qu’il y aura à l’avenir deux versions du JDK par an du fait que Java soit en concurrence directe avec d’autres plateformes qui sont mises à jour plus souvent. Après la sortie du JDK 12 le 19 mars prochain, il y aura donc très probablement une autre version du JDK courant cette année. Ceci étant dit, il semble qu’aucune fonctionnalité n’est en vue d’être ajoutée à cette version du JDK. Beaucoup d’internautes sur Reddit se disent impatients de pouvoir tester cette version du JDK et sont curieux de savoir ce que les prochaines versions de ce dernier réservent à la communauté.
Source : OpenJDK
Et vous ?
:fleche: Que pensez-vous de la RC1 de JDK 12 ?
:fleche: Cette version admissible comble-t-elle vos attentes ? Pourquoi ?
:fleche: Quelles autres fonctionnalités souhaiteriez-vous avoir dans le JDK 12 ?
Voir aussi
: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: Java 12 ne prendra probablement pas en charge les littéraux de chaîne bruts, la proposition d'amélioration JDK (JEP) suggère qu'on les supprime
: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)
Java 12 disponible avec les expressions Switch
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
Après la sortie de Java 9 en septembre 2017, Oracle a adopté un nouveau cycle de publication de six mois : une nouvelle version en mars et septembre de chaque année et une version LTS tous les 18 mois. Les versions intermédiaires seront donc des mises à jour de fonctionnalités qui ne se seront prises en charge que pendant 6 mois, le temps que la prochaine version arrive. Conformément à ce nouveau timing, Oracle vient d'annoncer la sortie de Java 12.
La nouvelle version apporte un certain nombre de nouvelles fonctionnalités et d’améliorations remarquables. Plus précisément, Java 12 inclut une nouvelle fonctionnalité de langage, les expressions Switch (en préversion), un nouveau récupérateur de mémoire à faible temps de pause appelé Shenandoah (expérimental) et diverses améliorations au récupérateur de mémoire par défaut Garbage First (G1). En tout, Java 12 introduit huit principales améliorations (JEP) que nous présentons ici.
Expressions Switch
Cette fonctionnalité en préversion étend l'instruction Switch afin qu'elle puisse être utilisée également en tant qu'expression. Le Switch n'est donc plus juste une structure de contrôle (comme les if/else), mais peut maintenant renvoyer une valeur. Avec cette fonctionnalité vient aussi une nouvelle syntaxe plus pratique et plus concise qui utilise l'opérateur arrow (->), et qui supprime le besoin d’instructions break. Précisons que seul le code à droite de -> est exécuté.
Ci-dessous un exemple de code avec le Switch classique : les nombreuses instructions break dans le code le rendent inutilement verbeux, ce qui peut souvent masquer des erreurs de débogage difficiles à identifier.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
switch (day) {
case MONDAY:
case FRIDAY:
case SUNDAY:
System.out.println(6);
break;
case TUESDAY:
System.out.println(7);
break;
case THURSDAY:
case SATURDAY:
System.out.println(8);
break;
case WEDNESDAY:
System.out.println(9);
break;
} |
Le code précédent peut être réécrit comme suit avec la nouvelle syntaxe utilisant -> et sans break :
Code:
1
2
3
4
5
6
7
|
switch (day) {
case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);
case TUESDAY -> System.out.println(7);
case THURSDAY, SATURDAY -> System.out.println(8);
case WEDNESDAY -> System.out.println(9);
} |
Code avec expression Switch :
Code:
1
2
3
4
5
6
7
|
int numLetters = switch (day) {
case MONDAY, FRIDAY, SUNDAY -> 6;
case TUESDAY -> 7;
case THURSDAY, SATURDAY -> 8;
case WEDNESDAY -> 9;
}; |
Collectes mixtes annulables pour G1
Il s'agit ici de pouvoir avorter les collectes G1 mixtes si elles risquent de dépasser la cible de pause. Si cela est nécessaire pour respecter la cible de temps de pause fournie par l'utilisateur, G1 (Garbage First) sera en effet contraint d'abandonner le processus de récupération de mémoire. Pour cela, le jeu de régions dans lesquelles la récupération de mémoire sera effectuée est divisé en parties obligatoires et facultatives. Ce qui permet à G1 d'avorter le processus de récupération des parties facultatives si le temps de pause n’est pas respecté.
Renvoi immédiat de la mémoire non utilisée par G1 au système d'exploitation
Java 12 améliore le récupérateur de mémoire G1 afin de renvoyer automatiquement le tas Java (la mémoire heap) au système d'exploitation. Il s'agissait en effet de faire en sorte que G1 renvoie les zones de mémoire collectées au système d'exploitation après une période de faible activité de l'application. Jusqu'à présent, G1 ne renvoyait la mémoire au système d’exploitation qu’après un Full GC, chose qu’il évitait d'ailleurs, car l'un des objectifs d’une JVM correctement paramétrée est d’avoir le moins de Full GC possible. Ce qui fait qu'en général, le récupérateur de mémoire G1 ne retournait pas du tout la mémoire effacée vers le système d’exploitation.
Archives CDS par défaut
Class Data Sharing (CDS) est une fonctionnalité de la JVM qui permet de réduire le temps de démarrage de celle-ci, en enregistrant dans un fichier les métadonnées des classes pour une réutilisation lors du prochain lancement de la JVM. Toutefois, si vous n'installez pas le JRE avec le programme d'installation, l'archive CDS n'est pas générée par défaut et la commande java -Xshare:dump doit être exécutée manuellement. Dans Java 12, les archives CDS seront générées par défaut sur les plateformes 64 bits, pas besoin d’argument spécifique dans la ligne de commande.
Un seul port ciblant l'architecture ARM 64 bits
Il existe deux ensembles différents de codes source (donc de ports) ciblant ARM 64 bits dans le JDK. L'un, fourni par Oracle, est arm64 (disponible dans le répertoire src/hotspot/cpu/arm) et l'autre est aarch64 (disponible dans le répertoire open/src/hotspot/cpu/aarch64). Dans Java 12, il y aura désormais un seul port ciblant l'architecture ARM 64 bits. Toutes les sources liées au port arm64 ont été supprimées tout en conservant le port ARM 32 bits et le port aarch64. La suppression d'un port 64 bits permettra à tous les contributeurs de concentrer leurs efforts sur une implémentation ARM 64 bits unique et d’éliminer le travail en double requis pour la maintenance de deux ports.
API de constantes JVM
Java 12 introduit une API pour modéliser les descriptions nominales des fichiers de classe clé et artefacts de runtime, en particulier des constantes pouvant être chargées à partir du pool de constantes.
Shenandoah, un ramasse-miettes à faible temps de pause
Java 12 ajoute un nouvel algorithme de récupération de mémoire réduisant les temps de pause du GC en effectuant le travail d'évacuation en même temps que les threads Java en cours d'exécution. Développé par Redhat et déjà inclus depuis plusieurs mois dans leur JVM, Shenandoah est intégré en tant que fonctionnalité expérimentale dans Java 12. Les temps de pause avec Shenandoah sont indépendants de la taille du tas, ce qui signifie que vous aurez les mêmes temps de pause, que votre tas soit de 200 Mo ou de 200 Go.
Suite de microbenchmarks
Java 12 vient avec une suite de base de microbenchmarks introduite au code du JDK. Les développeurs peuvent facilement exécuter les microbenchmarks existants et en créer de nouveaux.
Pas de littéraux de chaîne bruts (Raw String Literals)
Enfin, rappelons que les littéraux de chaîne bruts (Raw String Literals) ont été supprimées du JDK 12. Les littéraux de chaîne bruts facilitent l'utilisation de chaînes contenant des caractères spéciaux et des chaînes multilignes. Ils sont créés avec le symbole backtick (accent grave) : `. Il s'agissait également d'introduire la fonction String::align pour faciliter l’utilisation de texte multiligne indenté et les fonctions unescape/escape pour les conversions vers ou à partir de littéraux de chaîne (traditionnels). Mais cette fonctionnalité qui était prévue pour le JDK 12 a été supprimée au dernier moment. Elle pourrait réapparaître dans les versions à venir.
Source : Blog Oracle
Et vous ?
:fleche: Que pensez-vous des nouveautés et améliorations de Java 12 ?
:fleche: Lesquelles appréciez-vous le plus et pourquoi ?
:fleche: Comptez-vous migrer vers cette version ou attendre la prochaine LTS ?
Voir aussi :
:fleche: JavaFX disponible en version 12, la boite à outils graphique suit l'évolution de Java
:fleche: Quelle version de Java utilisez-vous ? Qu'est-ce qui vous empêche de migrer vers une version plus récente ?
: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: Quelles implémentations JPA (Java Persistence API) utilisez-vous et pourquoi ? Partagez votre expérience
Pas tout à fait en rapport avec les nouveautés
Voilà,
Pour les nouveautés ça a l'air chouette. Surtout l'amélioration du GC, qui me laisse espérer pour certains de mes projets.
Mon problème est que j'utilise un IDE payant, et je ne peux pas renouveler ma licence pour l'instant. L'IDE JetBrains ne reconnaît la string de version "10" "11" "12" parce que ... raison commerciale certainement en 2019.
Connaissez-vous un patch? Parce que Eclipse et Netbeans je ne sais pas les utiliser.
PS il y a bien une version gratuite des produits JetBrains pour une utilisation libre (ce qui est mon cas) mais apparemment quand on a payé une licence on ne sait pas rétrograder.
