Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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)

Le , par Bill Fassinou

301PARTAGES

12  0 
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
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 : Sélectionner tout
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 : Sélectionner tout
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 ?

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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Mickael_Istria
Membre émérite https://www.developpez.com
Le 21/03/2019 à 11:05
C'est justement l'occasion ou jamais d'apprendre a utiliser un IDE open-source et durable
3  0 
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 20/03/2019 à 23:32
A noter que l'expression switch supporte également les blocs multi-lignes entre {} et qu'il faut alors utiliser l'instruction break pour faire un retour de la valeur.

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
    public void assignValue(Size size) {
        int height = 0;
        height = switch(size) {
            case S -> 18;
            case M -> {
                    int weight = 19;
                    break (weight > 10 ? 15 : 20); 
                } 
            case L, XL -> 25;
        };
    }
A noter de plus qu'il ne s'agit pas la d'une fonctionnalité définitive mais d'une fonctionnalité en aperçu (Preview Language and VM Features), ce qui veut dire que oui elle est bien complète et fonctionnelle mais peut être modifiée ou retirée d'un prochain JDK si jamais il s’avère qu'elle cause trop de soucis.

Citation Envoyé par http://openjdk.java.net/jeps/12
A preview language or VM feature is a new feature of the Java SE Platform that is fully specified, fully implemented, and yet impermanent. It is available in a JDK feature release to provoke developer feedback based on real world use; this may lead to it becoming permanent in a future Java SE Platform.
Source : blog de intellij sur le support des switch expression dans Intellij 2019.1 disponible en Early Access (la version 2018.3 fonctionne avec le JDK 12 mais ne supporte pas cette syntaxe)

EDIT - Avis perso : je pense que syntaxiquement c’était une erreur de choisir break et que return aurait été plus le bienvenu a cet endroit. Même si le mécanisme sous-jacent est probablement différent de celui des méthode, lambda et autres classe anonyme et qu'il ont fait ce choix pour des raisons d’analyse syntaxique ou de compilateur, il semble plus logique pour le programmeur moyen que la valeur renvoyée par un bloc, quel qu'il soit, se fasse de manière unifiée par une instruction return. D'un autre cote il s'agit aussi d'un bloc d'expression comme pour similaire a un for ou un while et donc ça pourrait poser le soucis que ça laisserait penser a ce que cette instruction sorte de la méthode englobant le switch.
1  0 
Avatar de bouye
Rédacteur/Modérateur https://www.developpez.com
Le 21/03/2019 à 12:51
J'ai la version 2018.3 Community de Intellij IDEA et il fonctionne très bien avec les JDK 9, 10, 11 et 12 juste qu'il ne supporte le switch expression. La version 2019.1 qui est dispo sur le canal early access est sensé le supporter. Intellij IDEA ne supporte pas JLink par contre. Le supporte des modules fonctionne plutôt bien dans Intellij.

Apache NetBeans 10 supporte les JDK 8, 9 et 10 mais pas trop 11 il me semble (à vérifier) et encore moins le 12 (il me semble que c'est prévu pour NetBeans 11 d'après la roadmap chez Apache). Apache NetBeans supporte JLink et couplé avec le JDK 8 supporte très bien javapackager. Le support des modules est défaillant dans Apache NetBbeans lorsqu'on utilise des legacy jar avec noms de modules auto-générés, pour une raison que je ne m'explique pas Apache NetBeans n'utilise pas la même règle de génération de nom de module que le JDK.
1  0 
Avatar de atha2
Membre éprouvé https://www.developpez.com
Le 21/03/2019 à 0:55
Citation Envoyé par bouye Voir le message
A noter que l'expression switch supporte également les blocs multi-lignes entre {} et qu'il faut alors utiliser l'instruction break pour faire un retour de la valeur.

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
    public void assignValue(Size size) {
        int height = 0;
        height = switch(size) {
            case S -> 18;
            case M -> {
                    int weight = 19;
                    break (weight > 10 ? 15 : 20); 
                } 
        };
    }
EDIT - Avis perso : je pense que syntaxiquement c’était une erreur de choisir break et que return aurait été plus le bienvenu a cet endroit. Même si le mécanisme sous-jacent est probablement différent de celui des méthode, lambda et autres classe anonyme et qu'il ont fait ce choix pour des raisons d’analyse syntaxique ou de compilateur, il semble plus logique pour le programmeur moyen que la valeur renvoyée par un bloc, quel qu'il soit, se fasse de manière unifiée par une instruction return. D'un autre cote il s'agit aussi d'un bloc d'expression comme pour similaire a un for ou un while et donc ça pourrait poser le soucis que ça laisserait penser a ce que cette instruction sorte de la méthode englobant le switch.
J'imagine que les parenthèse sont optionnelles et qu'on peut écrire :
Code : Sélectionner tout
1
2
break weight > 10 ? 15 : 20;
?
Perso sans parler de l'aspect technique qui ne me parait pas pertinent dans le choix du mot clé, le choix du mot clé "break" me parait plus pertinent que "return". Pour interrompre le file d’exécution d'une méthode, on utilise le mot clé "return". Pour interrompe le file d’exécution d'une structure de contrôle (while, for switch), on utilise "for" (voir "continue".

Sinon plutôt (ou en complément) que break une autre syntaxe pourrait être pertinente :
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
    public void assignValue(Size size) {
        int height = 0;
        height = switch(size) {
            case S -> 18;
            case M -> {
                    int weight = 19;
                    weight > 10 ? 15 : 20; 
                } 
        };
    }
Comme dans pas mal de langage fonctionnel, l'évaluation d'un bloc d'instruction correspond à l’évaluation de la dernière instruction de ce bloc. Mais j'imagine qu'autoriser ça dans ce contexte forcerai à modifier le comportement des lambdas et du "return" classique afin d'uniformiser le langage.
0  0 
Avatar de DaTheWolf
Membre du Club https://www.developpez.com
Le 21/03/2019 à 7:35
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.
0  0 
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 25/03/2019 à 12:51
Les expressions switch ressemblent comme deux gouttes d'eau à celles qui arrivent en C# 8 (juste les flèches qui sont différentes : "->" en Java, "=>" en C#). Quant à savoir qui a copié l'autre, je ne m'avancerai pas... de toute façon Java et C# se sont toujours piqué des idées
0  0 
Avatar de Mickael_Istria
Membre émérite https://www.developpez.com
Le 25/03/2019 à 13:11
Eclipse IDE 2019-03 supporte bien Java 12 (et les switch expressions) en lui ajoutant cette extension: https://marketplace.eclipse.org/cont...se-2019-03-411
0  0