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

Le , par Bill Fassinou, Chroniqueur Actualités
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 ?

Qu'en pensez-vous ?
Selon vous, les littéraux devrait-ils être supprimés de JDK 12 ? Pourquoi ?

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

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

Java 8 ne va plus recevoir de mises à jour et correctifs de sécurité à partir de septembre à moins de passer à un support commercial


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de tomlev tomlev - Rédacteur/Modérateur https://www.developpez.com
le 13/12/2018 à 18:29
Ils se prennent bien la tête pour pas grand chose. La syntaxe C# est très simple (un préfixe @ avant le début de la chaine) et ne pose pas de souci majeur. Après je ne connais pas les spécificités de la feature qui était prévue pour Java, donc il est possible que quelque chose m'ait échappé...
Avatar de adiGuba adiGuba - Expert éminent sénior https://www.developpez.com
le 13/12/2018 à 20:22
@tomlev : le problème c'est justement le préfixe. Et c'est leurs boulots de se prendre la tête 😉

La solution de C# impose de doubler toutes les double-quotes de la chaîne, et l'objectif étant justement d'éviter cela...

Le ` a l'avantage d'être un peu moins utilisé (quoique).
Mais j'aime pas trop la syntaxe...
Avatar de redcurve redcurve - Membre confirmé https://www.developpez.com
le 13/12/2018 à 20:23
Citation Envoyé par tomlev Voir le message
Ils se prennent bien la tête pour pas grand chose. La syntaxe C# est très simple (un préfixe @ avant le début de la chaine) et ne pose pas de souci majeur. Après je ne connais pas les spécificités de la feature qui était prévue pour Java, donc il est possible que quelque chose m'ait échappé...
On parle de java la moindre fonctionnalité est un immense bordel infâme bref rien de nouveau sous la tasse de café
Avatar de Gugelhupf Gugelhupf - Modérateur https://www.developpez.com
le 13/12/2018 à 21:48
Le JDK12 offre une feature assez intéressante avec le Switch Expressions (JEP 325)

Avant :
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
int numLetters;
switch (day) {
    case MONDAY:
    case FRIDAY:
    case SUNDAY:
        numLetters = 6;
        break;
    case TUESDAY:
        numLetters = 7;
        break;
    case THURSDAY:
    case SATURDAY:
        numLetters = 8;
        break;
    case WEDNESDAY:
        numLetters = 9;
}
Avec Java 12:
Code : Sélectionner tout
1
2
3
4
5
6
int numLetters = switch (day) {
    case MONDAY, FRIDAY, SUNDAY -> 6;
    case TUESDAY                -> 7;
    case THURSDAY, SATURDAY     -> 8;
    case WEDNESDAY              -> 9;
};
Avatar de kbadache kbadache - Membre régulier https://www.developpez.com
le 13/12/2018 à 21:54
Citation Envoyé par redcurve Voir le message
On parle de java la moindre fonctionnalité est un immense bordel infâme bref rien de nouveau sous la tasse de café
Juste que ceux qui développent Java essaient de voir un peu plus loin que "Cette feature est trop génial, on l'a rajoute".
Rétrocompatibilité, utilisabilité, évolution futur...
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 14/12/2018 à 6:05
Citation Envoyé par tomlev Voir le message
Ils se prennent bien la tête pour pas grand chose. La syntaxe C# est très simple (un préfixe @ avant le début de la chaine) et ne pose pas de souci majeur. Après je ne connais pas les spécificités de la feature qui était prévue pour Java, donc il est possible que quelque chose m'ait échappé...
Le fonctionnement de C# a en effet l'avantage d'être simple, mais il n'est pas parfait, loin de là. La syntaxe des chaines préfixées par @ de C# n'est d'ailleurs pas un "raw string" dans le sens ou on l'entend en général, vu que le guillemet doit-être échappé.
Ce qu'on appelle habituellement, une "raw string", c'est une séquence de caractère sans aucune séquence d’échappement. C'est les délimiteurs de la séquence qui varient suivant le besoin du contenu.

Par exemple en Rust les chaines brutes sont préfixées par "r" et autant de "#" qu'il doit y en avoir après le guillemet fermant.
Code Rust : Sélectionner tout
1
2
3
4
let chaine_brute1 = r"Chaine pouvant contenir des \  sans échappement";
let chaine_brute2 = r#"Chaine pouvant aussi contenir des " sans échappement "#;
let chaine_brute3 = r##" Chaine pouvant aussi contenir un "# sans échappement "##;
...

De ce que j'ai compris du message de Brian Goetz, Java avait prévu d'utiliser le même nombre de backquote en début et fin de chaine, ce qui aurait donné:
Code text : Sélectionner tout
1
2
3
4
 
var chaine_brute1 = `Chaine pouvant contenir des \ et " sans échapement`;
var chaine_brute2 = ``Chaine pouvant aussi contenir des ` sans échappement``;
var chaine_brute3 = ```Chaine pouvant aussi contenir des `` sans échappement```;

Pour moi, certains des argument de Brian Goetz sont convaincants :
  • il n’y pas de voie directe pour démarrer ou de terminer un littéral de chaîne brute avec un backquote
  • il n’y plus beaucoup de caractères de ponctuation non utilisés en Java et il faudrait peut être garder la backquote pour d'autres futur usages. (l'argument est présent dans le message originel mais pas repris dans l'article developpez.com)


Pour les autres points, je suis moins d'accord, notamment parce que la coloration syntaxique résout la plupart des problèmes évoqués
Avatar de ijk-ref ijk-ref - Membre confirmé https://www.developpez.com
le 14/12/2018 à 12:39
Citation Envoyé par Uther Voir le message
les chaines brutes (…) il n’y plus beaucoup de caractères de ponctuation non utilisés
Quelqu'un a-t-il déjà suggéré une approche différente : la mise en forme de texte ?

Habituellement utilisé (dans les traitements de textes) pour souligner, mettre en gras ou en italique. Elle pourrait servir pour désigner (au compilateur) ce qui est du texte. Il n'y aurait donc plus besoin naturellement de séquences d'échappement.

Ceci casserait l'habitude de pouvoir travailler notre code avec un simple éditeur de texte mais serait-ce si mal ?

Code : Sélectionner tout
let chaine_brute_par_nature_elles_seraient_toutes_brutes = Chaine pouvant contenir des \  " ' sans besoins d'aucuns échappements;
Avatar de adiGuba adiGuba - Expert éminent sénior https://www.developpez.com
le 15/12/2018 à 6:56
Citation Envoyé par ijk-ref Voir le message
Ceci casserait l'habitude de pouvoir travailler notre code avec un simple éditeur de texte mais serait-ce si mal ?
Perso je ne souhaite pas cela du tout.
Qu'un EDI fassent une coloration syntaxique c'est une chose, mais il faut rester sur un format texte !

Déjà cela aurait un impact énorme sur l'écosystème, puisqu'il faudrait adapter tous les EDI et tous les outils manipulant le source, et ça fait beaucoup de monde !

Mais en plus on perdrait toute la simplicité du format texte, simplement pour "cacher" un séparateur.
Impossible de manipuler ou de générer du code à la volé de manière simple, car outre la structure du code il faudrait respecter ce nouveau format...
Avatar de ijk-ref ijk-ref - Membre confirmé https://www.developpez.com
le 16/12/2018 à 1:02
Citation Envoyé par adiGuba Voir le message
Perso je ne souhaite pas cela du tout.
Qu'un EDI fassent une coloration syntaxique c'est une chose, mais il faut rester sur un format texte !
Qu'est ce qui définit un format texte ? Rien n'empêcherait d'en avoir un avec des "flags" sur les caractères.

Sinon on peut aussi rester sur un format de texte classique mais l'EDI nous cachant la complexité des caractères d'échappements.

A l'instar de la touche "Verr Maj" un double clique sur la touche ["] pourrait nous mettre en mode "entrée de texte" et on pourrait écrire vraiment n'importe quoi même faire des retours à la lignes tant qu'on ne re double clique pas sur la touche ["] pour revenir en mode "code". En interne ça écrirait du code normal.

Si vous avez déjà écrit des expressions régulières, déjà que c'est assez dur de les relire, alors entre les caractères d'échappements du format texte... et ceux des expressions cela devient vite le bordel. Si il y avait un moyen (comme je viens de présenter) de les supprimer rendant le code plus lisible ce serait bien mieux.
Avatar de adiGuba adiGuba - Expert éminent sénior https://www.developpez.com
le 16/12/2018 à 8:57
Citation Envoyé par ijk-ref Voir le message
Qu'est ce qui définit un format texte ? Rien n'empêcherait d'en avoir un avec des "flags" sur les caractères.
Ben un format texte c'est un fichier constitué de caractères, donc ces flags seraient des caractères et c'est exactement de quoi il est question : comment choisir ces caractères en gardant une bonne lisibilité et sans avoir à utiliser de caractères d'échappement (ou le moins possible).

Citation Envoyé par ijk-ref Voir le message
Sinon on peut aussi rester sur un format de texte classique mais l'EDI nous cachant la complexité des caractères d'échappements.

A l'instar de la touche "Verr Maj" un double clique sur la touche ["] pourrait nous mettre en mode "entrée de texte" et on pourrait écrire vraiment n'importe quoi même faire des retours à la lignes tant qu'on ne re double clique pas sur la touche ["] pour revenir en mode "code". En interne ça écrirait du code normal.
Sauf que ça c'est une fonctionnalité de l'EDI, et non pas du langage.
Rien n'empêche un EDI de proposer cela dès maintenant... Mais on n'aurait plus une correspondance exact entre le code visible dans l'EDI et le fichier source...

Citation Envoyé par ijk-ref Voir le message
Si vous avez déjà écrit des expressions régulières, déjà que c'est assez dur de les relire, alors entre les caractères d'échappements du format texte... et ceux des expressions cela devient vite le bordel. Si il y avait un moyen (comme je viens de présenter) de les supprimer rendant le code plus lisible ce serait bien mieux.
Ben c'est exactement l'objectif de la proposition.
`a\. "hello" ` serait l'équivalent de "a\\. \"hello\"" .

Et le problème relevé, c'est que si ça marche super bien pour les expressions régulières, ça peut poser problème pour d'autres types de codes utilisant le caractère ` comme des scripts shell ou du SQL...

Le rythme des 6 mois entre chaque version permet de décaler ça pour y réfléchir encore un peu...
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web