Les lambda expressions dans Java 8

Durant cet été, l’actuel architecte de Java auprès d’Oracle, Brian Goetz, a fourni des informations intéressantes sur l’implémentation des lambda expressions dans le futur Java 8 et de ses conséquences sur le langage. Par lambda expression comprenez ici closure ou fonction anonyme, qu’il est possible de stocker dans une variable ou de retourner depuis une méthode ou depuis une autre fonction, et bien sûr d’appeler. L’intégration des lambda expressions se fait dans le cadre de la JSR 335 (JSR 335: Lambda Expressions for the JavaTM Programming Language), aussi appelé Lambda Project.

Du point vue d’Oracle, la stratégie donnée à Brian est celle-ci :

Oracle’s position is that Java must evolve – carefully, of course – in order to remain competitive. (« La position d’Oracle est que Java doit évoluer – prudemment, bien sûr – afin de rester compétitif. »)

À partir de quoi, Brian propose :

It is my belief that the best direction for evolving Java is to encourage a more functional style of programming. (« Je suis convaincu que la meilleure orientation pour l’évolution de Java est d’encourager un style de programmation plus fonctionnel. »)

Nous allons voir dans cet article, l’état des actuelles propositions faites pour étendre le langage Java vers un style fonctionnel.

Avertissement : Les informations présentes dans cet article sont celles qui ont été récupérées en date de publication de l’article. Tant que Java 8 n’est pas officiellement sorti, ces informations peuvent changer à tout instant.

De la nature des lambda expressions

La lambda expression est simplement une fonction anonyme, aussi appelée closure. Il est possible de les stocker dans des variables, définir des fonctions qui prennent en entrée d’autres fonctions et/ou retournent une fonction (voir l’article Comparaison d’API Java de programmation fonctionnelle). Les lambda expressions sont à la base de la programmation fonctionnelle.

Pour représenter les lambda expressions dans Java, Brian Goetz propose deux formes possibles : lambda-en-tant-qu’objet et lambda-en-tant-que-fonction. Le point de vue lambda-en-tant-qu’objet consiste à disposer d’une interface ou d’une classe représentant les fonctions, ce que Brian appelle le type fonction. Dans cette perspective, on aura des fonctions dérivant par exemple de l’interface suivante :

interface Function<T, R> {
    R apply(T arg);
}

Cette présentation des lambda expressions correspond à celle employée par Guava notamment. Mais du fait du type erasure, on obtient au niveau du bytecode quelque chose comme :

interface Function {
    Object apply(Object arg);
}

On perd ici toute information concernant le type d’entrée et de sortie de la fonction.

En fait, Brian préfère nous diriger vers une approche où les lambda expressions sont des éléments du langage à part entière et non des objets. Pour lui, la solution lambda-en-tant-qu’objet aurait été envisageable dans le cas où Java aurait permis la réification des types paramètres dans les types génériques, ou pour être plus exact la conservation des informations du type paramètre au niveau du bytecode. Mais comme Java applique le type erasure (ie. l’effacement du type paramètre au niveau du bytecode), Brian Goetz pense qu’il est préférable de se tourner vers la solution lambda-en-tant-que-fonction.

Reste à savoir ce que cela donnera au niveau du bytecode.

Syntaxe des lambda expressions

La solution retenue pour représenter les lambda expressions est basée sur la syntaxe C#. Ainsi, la représentation d’expression simple comme x+1 ou x+y pourrait s’écrire :

x => x + 1
(x) => x + 1
(int x) => x + 1
(x, y) => x + y
(int x, int y) => x + y

Sachant que la syntaxe n’est encore complètement décidée dans les détails, on pourrait très bien avoir :

x -> x + 1
(int x, int y) -> x + y
...

Dans le cas où vous voulez écrire votre fonction sur plusieurs lignes, vous devrez l’écrire ainsi :

(int x) => {
    if (x >= 18) System.out.println("majeur");
    else System.out.println("mineur");
}

Il reste à décider d’éléments de détail comme de la forme de la flêche, la façon d’écrire une lambda expression sans paramètre, l’obligation de mettre un return dans une lambda de plusieurs lignes quand elle retourne une valeur, etc.

Conclusion

La syntaxe choisie pour les lambda expressions est relativement claire et accessible. Reste à déterminer la syntaxe utilisée pour indiquer qu’une méthode ou une lambda prend en paramètre une autre lambda. Quoiqu’il en soit, l’arrivée de la programmation fonctionnelle dans Java ouvre des portes intéressantes tant le sujet est riche (nouveaux opérateurs sur les collections, collection infinie, maîtrise du futur d’une fonction, etc.). Mais en attendant, l’une des premières conséquences de l’arrivée des lambda expressions est la mise à jour de l’API Collection. Nous verrons dans un prochain article la nouveauté que sont les méthodes virtuelle d’extension, pour permettre à Java d’ajouter de nouveaux opérateurs dans l’API Collection en minimisant l’effort de développement.

Références

• Brian Goetz, A peek past lambda. OpenJDK Mailing list, Project Lambda. 2011-08-18 :
  http://mail.openjdk.java.net/pipermail/lambda-dev/2011-August/003877.html
• Brian Goetz, Call for input – point lambdafication. OpenJDK Mailing list, Project Lambda. 2011-08-24 :
  http://mail.openjdk.java.net/pipermail/lambda-dev/2011-August/003919.html
• Brian Goetz, Syntax decision. OpenJDK Mailing list, Project Lambda. 2011-09-08 :
  http://mail.openjdk.java.net/pipermail/lambda-dev/2011-September/003936.html