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 : | Sélectionner tout |
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 : | Sélectionner tout |
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 |
| Code : | Sélectionner tout |
1 2 3 4 5 |
String s = `
this is my
embedded string
`; |
| Code : | Sélectionner tout |
1 2 3 4 5 |
String html = `
this is my
embedded string
`; |
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 ?
Qu'en pensez-vous ?Voir aussi
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 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 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 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 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 
Envoyé par http://openjdk.java.net/jeps/12
