Voir le flux RSS

bouye

[Actualité] JEP 286 : inférence du type des variables locales

Note : 2 votes pour une moyenne de 5,00.
par , 14/03/2016 à 22h59 (2553 Affichages)
Un reproche qui revient régulièrement en ce qui concerne Java est le fait que le langage semble plutôt « verbeux » comparé à d'autres langages plus modernes. Par exemple, il convient d'écrire :

Code Java : Sélectionner tout - Visualiser dans une fenêtre à part
LinkedList<String> stringList = new LinkedList<String>()

Même si des améliorations dans le langage apportées lors des JDK 7 et 8 permettent désormais d'écrire LinkedList<String> stringList = new LinkedList<>(), voire LinkedList<String> stringList = new LinkedList() (au prix de quelques warnings suivant la configuration de votre IDE), il reste que la déclaration obligatoire du type à gauche est redondante dans bien des cas et peut sembler assez souvent inutile.

Une nouvelle proposition d'amélioration du JDK (JEP ou JDK Enhancement Proposal) en date du 8 mars 2016 vient de voir le jour, la JEP 286: Local-Variable Type Inference. Le but de cette nouvelle proposition est d'introduire le type réservé var ou val pour permettre donc de rendre les déclarations des variables locales plus concises et ainsi se rapprocher de ce qui se fait dans des langages concurrents (*atchoum* C# *atchoum* ; ainsi le typeréservé auto du C++ n'aura pas été retenu). La proposition mentionne également qu'il serait possible d'introduire val ou let en tant que raccourci syntaxique pour final var.

Si la proposition est retenue, ce mot serait utilisable pour les variables locales, les boucles for-each et les boucles for traditionnelles. Il ne serait pas utilisable pour les paramètres de méthode ou d'un constructeur, la valeur de retour d'une méthode, le catch ou encore la déclaration des membres d'une classe. Il deviendra alors possible d'écrire dans une variable locale d'une méthode : var list = new LinkedList<String>(); (le type est explicite puisque la variable est initialisée via l'appel d'un constructeur) ou encore var stream = list.stream(); (ici le type est inféré d'après le type de retour de la fonction).

De plus, certains aménagements dans les règles habituelles seront nécessaires : il y a trop de code existant pouvant utiliser var ou val comme nom de variable, et il est donc impossible de faire que ces mots soient définis en tant que mots-clés du langage d'où le choix d'un type réservé. Enfin, un travail de simplification doit être fait au niveau du compilateur pour rendre les messages d'erreurs plus facilement interprétables par le programmeur dans les cas suivants où l'inférence est impossible :


-> erreur : la variable n'est pas initialisée, impossible d'inférer son type.

Code Java : Sélectionner tout - Visualiser dans une fenêtre à part
var f = () -> { };

-> erreur : le type de la lambda doit être explicite.


-> erreur : initialisé à null, impossible d'inférer son type.


-> erreur : impossible de dénoter le type inféré (? il faudrait voir le type déclaré de l() dans le code de test).


-> erreur : le type de la référence de méthode doit être explicite.

Code Java : Sélectionner tout - Visualiser dans une fenêtre à part
var k = { 1 , 2 };

-> erreur : le type du tableau doit être explicite.

Envoyer le billet « JEP 286 : inférence du type des variables locales » dans le blog Viadeo Envoyer le billet « JEP 286 : inférence du type des variables locales » dans le blog Twitter Envoyer le billet « JEP 286 : inférence du type des variables locales » dans le blog Google Envoyer le billet « JEP 286 : inférence du type des variables locales » dans le blog Facebook Envoyer le billet « JEP 286 : inférence du type des variables locales » dans le blog Digg Envoyer le billet « JEP 286 : inférence du type des variables locales » dans le blog Delicious Envoyer le billet « JEP 286 : inférence du type des variables locales » dans le blog MySpace Envoyer le billet « JEP 286 : inférence du type des variables locales » dans le blog Yahoo

Mis à jour 17/03/2016 à 09h14 par ClaudeLELOUP

Catégories
Java , Java

Commentaires

Page 2 sur 2 PremièrePremière 12
  1. Avatar de adiGuba
    • |
    • permalink
    Citation Envoyé par tomlev
    Les langages s'influencent mutuellement, et c'est très bien comme ça ; ce n'est pas du plagiat.
    En même temps si les langages évoluent c'est normal qu'ils puisse s'intéresser à des concepts proche.
    Mais malgré tout on reste comme tu le dit bien souvent sur des approches très différentes dans les deux cas...


    a++
  2. Avatar de bouye
    • |
    • permalink
    Le numéro de Janvier/Fevrier 2017 du Java Magazine d'Oracle revient sur la JSR-286 avec en page 60 (61 dans le PDF) une interview de Brian Goetz, architecte du langage Java qui explique qu'au final seul var a été retenu alors qu'un sondage auprès du groupe de test avait donne la proposition "var et val" gagnante. Les raisons avancées etant :
    • Cette proposition avait eut le plus de voix pour... mais aussi le plus de voix contre...
    • La lisibilité du code.
    • Ce n'est pas important de rendre les variables locales final ; leur solution consiste donc à "donner à la variable un nom qui indique qu'elle doit être non-mutable " car var permet de mieux lire le code..................................... (je désapprouve mais bon, ce n'est que mon avis...)
Page 2 sur 2 PremièrePremière 12