Proposition pour la prise en compte de l'inférence du type dans une prochaine version de #Java

Le mot clé var ferait son apparition

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 :


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.


-> 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.


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