Nouveaux mots clés en Java

Dans un avenir proche, de nouvelles fonctionnalités apparaîtront dans le langage Java, qui sont actuellement en cours d'élaboration dans le cadre des projets de Valhalla, Panama et Loom. Développer une langue n'est pas une tâche facile, surtout pas une langue dans laquelle l'accent est mis sur la compatibilité descendante; par conséquent, pour que leur intégration dans Java se déroule sans problème, les architectes de langage doivent résoudre les problèmes fondamentaux accumulés.

Hier (8 janvier), Brian Goetz, travaillant pour Oracle en tant qu'architecte de langage Java, a publié une lettre «Nous avons besoin de plus de mots-clés, capitaine!» Sur la liste de diffusion de Project Amber . dans lequel il a proposé un moyen de résoudre le problème de l'ajout de nouveaux mots clés à la langue. Par conséquent, les mots clés peuvent apparaître dans la langue telle que non nul , non final , éventuellement final et this-return (une liste complète vous attend sous le découpage à la fin du post).

Comme par le passé ce problème se posait rarement dans la langue, ils n'y pensaient généralement pas beaucoup et «essayaient de se déchaîner le plus rapidement possible»; en raison des lacunes des approches existantes à l'avenir, leur application sera problématique et, à cet égard, il a été décidé de travailler à l'avance. Solution proposée: essayer d'élargir l'ensemble des formes lexicales pouvant être utilisées comme mots clés: autoriser les mots clés séparés par un trait d'union, qui utiliseront un (ou plusieurs) mots clés existants ou un identifiant réservé.

Remarque importante: Brown note que les nouveaux mots clés sont fournis uniquement à titre d'exemple et que vous ne devez pas vous concentrer sur eux. Cependant, il est évident que nous avons devant nous une démonstration réfléchie de la façon dont la syntaxe du langage pourrait changer à l'avenir - dans la lettre, l'auteur mentionne que cette idée aidera à ajouter de nombreuses constructions de langage manquantes souhaitables à Java.

"Anciennes" méthodes

Comme vous le savez, il existe aujourd'hui dans le langage Java 50 mots-clés ( mots-clés ), dont l'utilisation est interdite comme identifiants des variables. Une liste complète est donnée dans la spécification du langage JLS dans la clause 3.9 . Cette liste n'a pas beaucoup changé depuis la première version du langage - seule l' assertion a été ajoutée dans la version 4, l' énumération dans 5 et _ dans 9. En plus d'eux, il existe également des «identifiants réservés» - vrai , faux et nul - qui se comportent de manière similaire aux mots clés façon.

Lorsque les développeurs doivent ajouter un nouveau mot clé à la langue, ils doivent recourir à l'une des méthodes suivantes.

• Transfert de propriété forcé: nous prenons les mots qui étaient auparavant des identifiants et les transformons en mots clés (par exemple, affirmer ).
• Élimination: un mot-clé existant commence à être utilisé d'une manière qui n'a jamais été destinée à être utilisée (un exemple est l'utilisation de la valeur par défaut pour les valeurs d'annotation ou les méthodes par défaut).
• Ne vous en servez pas: trouvez un moyen d'utiliser une syntaxe qui ne nécessite pas de nouveau mot clé - par exemple, utilisez l' interface pour les annotations au lieu d' annotation - ou abandonnez complètement la fonctionnalité.
• Créer de la visibilité: créez l'illusion de mots clés contextuels à l'aide de réalisations linguistiques héroïques ( mots clés restreints, noms de types réservés ).

En principe, chacune de ces méthodes peut généralement être appliquée, mais chacune a ses inconvénients, et pour une extension sérieuse à grande échelle du langage, ces méthodes seules ne sont clairement pas suffisantes - pour les innovations futures, il sera nécessaire d'éliminer l'incapacité à étendre complètement la syntaxe du langage.

Ajout de nouveaux mots clés

Il y a les arguments suivants contre «juste» la prise et l'ajout de nouveaux mots.

• Plus le mot-clé sélectionné est pratique et populaire, plus il apparaîtra souvent dans le code source des programmes, ce qui ajoutera une incompatibilité au langage (par exemple, lorsque le mot assert est apparu dans Java SE 1.4, tous les frameworks de test ont cessé de fonctionner).
• Le coût de l'élimination d'une telle incompatibilité de code par le développeur variera considérablement de petit (renommer une variable locale) à fatal (lorsqu'une méthode d'interface ou un type public est invalidé).
• Les mots que les développeurs de langage sont les plus susceptibles d'utiliser sont des identifiants populaires (par exemple, valeur , var ou méthode );
• Si vous choisissez des mots qui sont rarement utilisés dans le code source et avec lesquels il y aura moins de collisions, vous devrez utiliser des constructions comme habituellement_mais_not_always_final , ce qu'il serait naturellement souhaitable d'éviter dans le langage.
• Si, cependant, vous avez recours à des mots rarement utilisés, l'utilisation trop fréquente de cette méthode ne fonctionnera pas - casser la compatibilité n'est pas bon, et il n'y a pas tellement de combinaisons plus réussies.

Réutilisation des "anciens" mots clés

À propos de «simplement» continuer à vivre avec ces mots, il y a des considérations.

• Des précédents de réutilisation des mots-clés dans différents contextes se retrouvent dans de nombreux langages de programmation (un exemple de Java est l'utilisation de ( (ab) use ) final pour les désignations «non mutable», «non redéfini» et «non extensible»).
• Parfois, cette approche est logique et vient d'elle-même, mais ce n'est généralement pas une priorité.
• Au fil du temps, l'ensemble des exigences pour un ensemble de mots clés s'élargit, et cela peut arriver à un point drôle - personne ne veut utiliser null final dans leur code.
• Si ce dernier vous a semblé exagéré, gardez à l'esprit qu'en travaillant sur JEP 325, ils ont sérieusement suggéré d'utiliser la nouvelle construction de commutateur pour décrire le commutateur avec une sémantique différente - si vous continuez dans la même veine, après dix ans, nous pouvons atteindre nouveau nouveau commutateur .

Comment vivre sans nouveaux mots clés? Il est possible d'arrêter complètement de s'engager dans l'évolution du langage, comme certains l'ont suggéré. Mais ce n'est pas grave et ne correspond pas à l'opinion des autres, car les développeurs ont un intérêt sain pour les nouvelles fonctionnalités du langage.

Mots-clés contextuels

Les mots-clés contextuels qui sont utilisés pour fournir une signification spécifique dans le code, mais qui ne sont pas des mots réservés ( utilisés en C # ) semblent à première vue être la même «baguette magique», mais ici, Brian donne son propre point de vue sur leur utilisation, basé sur la pratique ( par exemple, les implémentations var dans Java 10, qui n'est pas un mot-clé, mais un nom de type réservé ). En échange de l'illusion d'ajouter de nouveaux mots clés sans avoir à «casser» les programmes existants, nous obtenons une complexité et une distorsion accrues dans la langue.

Les mots clés contextuels sont difficiles pour les rédacteurs de spécifications, les compilateurs et les IDE. Dans le cas d'un ou deux cas spéciaux, cela ne pose pas de problème, mais lorsqu'ils commencent à être utilisés partout, cela se traduit par un coût beaucoup plus élevé de prise en charge du code ou de la queue des bogues.

On pourrait rejeter cela - ils disent que ce n'est pas un problème des utilisateurs de la langue, mais de ses créateurs et de ceux qui écrivent des compilateurs et des IDE. Mais en réalité, tout le monde souffre. Pour l'IDE, cela peut être un problème important: plus de saisie sera nécessaire pour deviner ce que le développeur entre - un mot-clé contextuel ou un identifiant. En conséquence, les utilisateurs obtiennent une détérioration du travail de mise en évidence de la syntaxe, d'auto-complétion et de refactorisation.

Vous pouvez utiliser cet outil, mais faites-le avec prudence.

Distorsion de la langue

Il semblerait qu'avec les problèmes que ces approches causent - syntaxe maladroite, complication inutile de la vie et bugs - en principe, nous pourrions le supporter. Mais il y a un autre problème qui n'est pas le plus évident - les nuances liées à l'utilisation de mots clés conduisent au fait que la conception de la langue elle-même est déformée.

Pour les développeurs Java, écrire une interface au lieu d' annotation est courant aujourd'hui, mais tout le monde conviendra que l'utilisation du terme convivial annotation au lieu d'une combinaison de @ et de l'ancien mot-clé serait beaucoup plus logique.

Autre exemple: l'ensemble des modificateurs disponibles (public, privé, statique, final, etc.) ne peut pas être qualifié de complet - nous ne pouvons rien dire de non final ou de statique . À son tour, cela signifie que vous ne pouvez pas créer d'entités dans lesquelles les variables ou les classes sont finales par défaut, ou les membres sont statiques par défaut, car il n'y a aucun moyen d'indiquer que nous aimerions abandonner ce modificateur.

Ce problème n'est pas si évident pour ceux qui utilisent la langue - mais les auteurs de la langue elle-même, en raison de leur désir de la développer davantage, la rencontrent constamment, et nous devons tous payer pour de telles décisions (quand explicitement, implicitement).

La conclusion de tout ce qui précède se suggère: nous avons besoin d'une autre source de mots clés.

Solution proposée

Dans les capacités expérimentales du langage, une syntaxe est utilisée pour pré-désigner de nouveaux mots clés, dans lesquels les nouveaux mots clés eux-mêmes sont précédés de deux traits de soulignement (par exemple, dans le prototype Project Valhalla, il s'agit de __ByValue ). La raison de cette décision est compréhensible - vous devez souligner qu'il s'agit d'un remplacement temporaire, pour lequel vous devrez à l'avenir prendre une décision sur la syntaxe finale, et en même temps, vous pouvez facilement éviter les conflits avec le code existant. On pourrait suggérer d'utiliser un format similaire pour les nouveaux mots clés - en commençant par un ou deux traits de soulignement - mais cette solution ne peut pas être qualifiée de belle, car dans ce cas, nous obtiendrons la confusion des mots clés ordinaires et nouveaux.

Par conséquent, il est proposé d'utiliser des mots clés construits à l'aide d'un trait d'union, qui utiliseront un ou plusieurs «anciens» mots clés ou identifiants réservés.

Contrairement aux mots - clés restreints , cette approche créera beaucoup moins de problèmes d'analyse, car (ci-après dénommé exemple) ne peut pas être confondu avec une expression de soustraction, et un lexer peut toujours déterminer si ab est trois jetons ou un. Grâce à cela, de nouvelles opportunités s'ouvrent à nous pour créer des mots clés qui sont beaucoup moins susceptibles d'entrer en conflit avec le code source existant ou entre eux. En plus de cela, ils sont beaucoup plus susceptibles d'avoir des noms significatifs, car une grande partie de ce que les créateurs du langage veulent ajouter à Java est basé sur des constructions de langage existantes - par exemple, non nulles .

A titre d'exemples de nouveaux mots-clés, des candidats probables à la place de nouveaux mots-clés sont donnés (je rappelle que selon l'auteur, pour l'instant cette liste est purement illustrative):

- non nul ;
- non final ;
- package-private (modificateur du niveau d'accès aux membres de la classe par défaut, qui n'est actuellement indiqué en aucune façon);
- lecture publique ( lecture publique, enregistrement privé);
- vérifié nul ;
- type-statique (le concept nécessaire pour Valhalla ; désigne statique par rapport à la spécialisation spécifique de la classe, et non la classe elle-même);
- valeur par défaut ;
- éventuellement final (ce qui est maintenant censé être fait en utilisant l'annotation Stable ),
- demi-finale (comme alternative à scellé );
- commutateur exhaustif ;
- enum-class , annotation-class , record-class (les auteurs de langues pourraient utiliser ces mots clés comme alternative à enum et interface , s'ils en avaient l'occasion);
- this-class (pour décrire le littéral de classe pour la classe actuelle);
- this-return (souvent demandé d'ajouter un moyen de marquer le setter / method-builder comme retournant son destinataire).

Il existe sûrement d'autres variantes de schémas lexicaux selon lesquels il serait possible de composer des mots-clés pour qu'ils se chevauchent au minimum avec ceux déjà écrits par le code source. Le trait d'union proposé est suffisamment lisible pour les voitures et les humains.

Il est entendu que cette approche n'exclut nullement la possibilité de l'utiliser avec celles qui ont été utilisées auparavant, mais sera utilisée avec elles.