Lambdas

Une première manière de définir le comparateur consiste à écrire une classe le représentant, nommée p.ex. IIC (pour inverse integer comparator). Cette classe peut naturellement être imbriquée statiquement dans la classe Sorter et rendue privée, car elle est avant tout destinée à être utilisée par sortDescending. On obtient alors¹ :

public final class Sorter {
  public static void sortDescending(List<Integer> l) {
    l.sort(new IIC());
  }

  private static class IIC implements Comparator<Integer> {
    @Override
    public int compare(Integer i1, Integer i2) {
      if (i2 < i1)
        return -1;
      else if (i2.equals(i1))
        return 0;
      else // i2 > i1
        return 1;
    }
  }
}

Ce code peut être simplifié au moyen de la méthode (statique) compare de la classe Integer, qui compare deux entiers et retourne un entier exprimant leur relation, exactement comme la méthode compare de l'interface Comparator. En lui passant les entiers à comparer dans l'ordre inverse, on obtient bien le résultat escompté. La méthode compare du comparateur se simplifie alors ainsi :

public final class Sorter {
  public static void sortDescending(List<Integer> l) {
    l.sort(new IIC());
  }

  private static class IIC implements Comparator<Integer> {
    @Override
    public int compare(Integer i1, Integer i2) {
      return Integer.compare(i2, i1);
    }
  }
}

Même s'il fonctionne, le code ci-dessus est relativement lourd à écrire au vu de la simplicité de la tâche à réaliser.

Une première manière d'alléger le code ci-dessus consiste à utiliser ce que l'on nomme en Java une classe intérieure anonyme (anonymous inner class).

Comme ce nom le suggère, une classe intérieure anonyme n'est pas nommée, contrairement à IIC plus haut. Au lieu de cela, sa définition apparaît directement après l'énoncé new qui crée son instance. Dès lors, une telle classe n'est utile que s'il n'y a qu'un seul endroit dans tout le programme où l'on désire créer une de ses instances. Comme c'est le cas dans l'exemple plus haut, il est possible de récrire la classe Sorter ainsi :

public final class Sorter {
  public static void sortDescending(List<Integer> l) {
    l.sort(new Comparator<Integer>() {
        @Override
        public int compare(Integer i1, Integer i2) {
          return Integer.compare(i2, i1);
        }
      });
  }
}

Il peut sembler étrange que le mot-clef new soit suivi du nom Comparator, puisque Comparator désigne une interface, et que les interfaces ne sont pas instanciables. Toutefois, lorsqu'on utilise une classe intérieure anonyme, le nom qui suit le mot-clef new n'est pas le nom de la classe dont on désire créer une instance — puisqu'elle est anonyme — mais bien le nom de sa super-classe ou, comme ici, de l'interface qu'elle implémente. Ce nom est suivi des éventuels paramètres de son constructeur entre parenthèses, puis du corps de la classe entre accolades.

Cette nouvelle version de la classe Sorter est préférable à la précédente car elle est plus simple et la totalité du code lié au tri par ordre décroissant se trouve à l'intérieur de la méthode sortDescending. Néanmoins, la définition de la classe intérieure anonyme reste lourde.

Heureusement, depuis la version 8 de Java, une syntaxe beaucoup plus légère permet d'écrire ce comparateur sans devoir définir explicitement une classe auxiliaire, nommée ou non. En utilisant cette syntaxe, on peut définir la méthode sortDescending simplement ainsi :

public final class Sorter {
  public static void sortDescending(List<Integer> l) {
    l.sort((i1, i2) -> Integer.compare(i2, i1));
  }
}

En comparant cette version à la précédente, on constate que le comparateur passé à sort est obtenu simplement en écrivant le corps de sa méthode compare — sans return — précédé d'une flèche (->) et du nom de ses deux arguments entre parenthèses, ici i1 et i2. Cette construction est connue sous le nom de lambda.²

Pour mémoire, depuis Java 8, les interfaces peuvent contenir des méthodes concrètes, qui peuvent être :

• des méthodes statiques, ou
• des méthodes par défaut (default methods), non statiques, qui sont héritées par toutes les classes qui implémentent l'interface et ne les redéfinissent pas.

Une interface est appelée interface fonctionnelle (functional interface) si elle possède exactement une méthode abstraite. Elle peut néanmoins posséder un nombre quelconque de méthodes concrètes, statiques ou par défaut.

Par exemple, l'interface Comparator est une interface fonctionnelle, car elle ne possède qu'une seule méthode abstraite, à savoir compare. Il se trouve qu'elle possède également d'autre méthodes, aussi bien statiques que par défaut, qui n'ont pas été présentées à la §2 dans un soucis de simplicité. Toutefois, comme il s'agit de méthodes concrètes et non abstraites, Comparator reste une interface fonctionnelle.

Un autre exemple d'interface fonctionnelle est l'interface RealFunction ci-dessous, qui pourrait représenter une fonction mathématique des réels vers les réels :

@FunctionalInterface
public interface RealFunction {
  public double valueAt(double x);
}

Comme cet exemple l'illustre, les interfaces fonctionnelles peuvent être annotées au moyen de l'annotation @FunctionalInterface. Cette annotation est optionnelle, mais utile car elle garantit qu'une erreur est produite si l'interface à laquelle on l'attache n'est pas fonctionnelle, p.ex. car elle comporte plusieurs méthodes abstraites.

En Java, une lambda, aussi appelée fonction anonyme (anonymous function) ou parfois fermeture (closure), est une expression créant une instance d'une classe anonyme qui implémente une interface fonctionnelle.

La lambda spécifie uniquement les arguments et le corps de la méthode abstraite de l'interface fonctionnelle. Ceux-ci sont séparés par une flèche symbolisée par les deux caractères -> :

arguments -> corps

Une lambda ne peut apparaître que dans un contexte qui attend une valeur dont le type est une interface fonctionnelle. La raison de cette restriction est claire : étant donné que la lambda ne spécifie pas le nom de la méthode qu'elle implémente, il faut que Java puisse le déterminer sans ambiguïté. Or cela n'est possible que si la lambda apparaît dans un contexte dans lequel la valeur attendue a pour type une interface fonctionnelle, c-à-d dotée d'une unique méthode abstraite.

Par exemple, l'expression suivante est valide :

Comparator<Integer> c = (x, y) -> Integer.compare(x, y);

car Comparator est une interface fonctionnelle, et il est donc clair que la lambda correspond à la méthode compare de cette interface. Par contre, l'expression suivante n'est pas valide :

Object c = (x, y) -> Integer.compare(x, y);

car Object n'est pas une interface fonctionnelle et on ne peut donc savoir à quelle méthode correspond la lambda.

Pour mémoire, les collections Java peuvent en général être parcourues au moyen d'un itérateur, que l'on obtient grâce à la méthode iterator. Cette méthode est définie dans l'interface Iterable, destinée à être implémentée par toute classe « itérable », c-à-d dont le contenu peut être parcouru de cette manière.

En plus de la méthode abstraite iterator, l'interface Iterable offre la méthode par défaut forEach, qui permet de parcourir le contenu de la collection sans devoir créer explicitement un itérateur. Attention, cette méthode ne doit pas être confondue avec la boucle for-each déjà examinée !

La méthode forEach est définie ainsi dans Iterable :

public interface Iterable<T> {
  default void forEach(Consumer<T> action) { /* … */ }
}

Son argument est ce que la bibliothèque Java nomme un consommateur (consumer), décrit par l'interface fonctionnelle Consumer du paquetage java.util.function, qui ressemble à ceci :

public interface Consumer<T> {
  void accept(T t);
}

La méthode forEach de Iterable appelle simplement la méthode accept du consommateur pour chacun des éléments de la collection, dans l'ordre d'itération. Elle pourrait donc se définir très facilement, par exemple au moyen d'une boucle for-each :

public interface Iterable<T> {
  default void forEach(Consumer<T> action) {
    for (T element: this)
      action.accept(element);
  }
}

Étant donné que l'interface Consumer est une interface fonctionnelle, l'argument passé à la méthode forEach peut être une lambda. Ainsi, pour afficher à l'écran tous les éléments d'une liste de chaînes, on peut écrire :

List<String> list = /* … */;
list.forEach(e -> System.out.println(e));

Comme nous l'avons vu dans la leçon sur les collections, les tables associatives ne sont malheureusement pas itérables : elles n'implémentent pas l'interface Iterable, et leur contenu ne peut donc pas être parcouru au moyen d'un itérateur ou de la boucle for-each.

La seule solution que nous connaissons à ce stade pour parcourir une table associative consiste donc à parcourir l'ensemble de ses paires clef/valeur, sur lequel on peut obtenir une vue au moyen de la méthode entrySet. Par exemple, pour afficher toutes les paires clef/valeur d'une table associative map, on peut écrire :

Map<String, Integer> map = /* … */;
for (Map.Entry<String, Integer> e : map.entrySet()) {
  String k = e.getKey();
  int v = e.getValue();
  System.out.println(k + " : " + v);
}

Le fait de devoir manipuler les paires clef/valeur rend ce code relativement lourd. Heureusement, l'interface Map offre une méthode forEach similaire à celle offerte par les listes mais prenant en argument une lambda à deux arguments : le premier est la clef, le second la valeur qui lui est associée. Au moyen de cette méthode, le code ci-dessus se récrit beaucoup plus agréablement ainsi :

Map<String, Integer> map = /* … */;
map.forEach((k, v) -> System.out.println(k + " : " + v));

Le type de l'argument de forEach est BiConsumer, une interface fonctionnelle qui n'est rien d'autre qu'une version à deux arguments (d'où le préfixe bi) d'un consommateur :

public interface BiConsumer<T, U> {
  void accept(T t, U u);
}

En plus de la méthode forEach, l'interface Map offre plusieurs méthodes destinées à être utilisées avec des lambdas et qui simplifient souvent la manipulation des tables associatives.

Par exemple, pour compter le nombre d'occurrences de chaque mot dans une liste words, on peut écrire la boucle suivante :

List<String> words = List.of("to","be","or","not","to","be");
Map<String, Integer> count = new HashMap<>();
for (String w: words) {
  if (! count.containsKey(w))
    count.put(w, 1);
  else
    count.put(w, count.get(w) + 1);
}

Le corps de la boucle distingue deux cas : si le mot n'a pas encore été rencontré, et ne fait donc pas partie de la table, il y est ajouté avec un nombre d'occurrences de 1 ; sinon, le nombre d'occurrences actuel est extrait et incrémenté.

Il est très fréquent d'écrire ce genre de code lorsqu'on utilise une table associative, et pour cette raison l'interface Map offre la méthode merge permettant de le simplifier. En l'utilisant, la boucle ci-dessus peut se récrire ainsi :

Map<String, Integer> count = new HashMap<>();
for (String w: words)
  count.merge(w, 1, (c, v) -> c + 1);

Il est fréquent de devoir trier des listes en utilisant un critère de tri différent de celui par défaut. Par exemple, on peut vouloir trier une liste de chaînes par longueur plutôt que par ordre alphabétique.

Pour ce faire, on peut utiliser la méthode sort de List en lui passant en argument un comparateur comparant les chaînes par longueur. Ce comparateur peut bien entendu s'écrire au moyen d'une lambda :

List<String> l = Arrays.asList("bas","bras","as","a","sabre");
l.sort((s1, s2) -> Integer.compare(s1.length(), s2.length()));

Il est toutefois possible de simplifier encore la définition de ce comparateur, en utilisant la méthode statique comparing de Comparator. Cette méthode prend en argument une lambda qui reçoit en argument un des éléments à comparer et retourne la valeur à utiliser pour la comparaison. Ainsi, l'appel à sort ci-dessus peut se récrire :

l.sort(Comparator.comparing(s -> s.length())

En utilisant une référence de méthode, concept décrit à la section suivante, ce code peut être rendu encore plus concis :

l.sort(Comparator.comparing(String::length))

Une référence à une méthode statique s'obtient simplement en séparant le nom de la classe de celui de la méthode par un double deux-points. Par exemple, comme on l'a vu, un comparateur ne faisant rien d'autre qu'utiliser la méthode statique compare de la classe Integer peut s'écrire ainsi :

Comparator<Integer> c = Integer::compare;

ce qui est équivalent à, mais plus concis que :

Comparator<Integer> c =
  (s1, s2) -> Integer.compare(s1, s2);

Il est également possible d'obtenir une référence de méthode sur un constructeur, en utilisant le mot-clef new en lieu et place du nom de méthode statique. Par exemple, un fournisseur de nouvelles instances vides de ArrayList<Integer> peut s'écrire :

Supplier<ArrayList<Integer>> lists = ArrayList::new;

ce qui est équivalent à, mais plus concis que :

Supplier<ArrayList<Integer>> lists =
  () -> new ArrayList<>();

Aussi étrange que cela puisse paraître, une référence à une méthode non statique peut également s'obtenir en séparant le nom de la classe du nom de la méthode par un double deux-points. Par exemple, un comparateur sur les chaînes ne faisant rien d'autre qu'utiliser la méthode (non statique !) compareTo des chaînes peut s'écrire :

Comparator<String> c = String::compareTo;

ce qui est équivalent à, mais plus concis que :

Comparator<String> c =
  (s1, s2) -> s1.compareTo(s2);

Notez que l'objet auquel on applique la méthode devient le premier argument de la lambda ! Il y a donc une différence cruciale entre une référence à une méthode statique et la première variante d'une référence à une méthode non statique ci-dessus :

• une référence à une méthode statique produit une lambda ayant le même nombre d'arguments que la méthode,
• une référence à une méthode non statique produit une lambda ayant un argument de plus que la méthode, cet argument supplémentaire étant le récepteur, c-à-d l'objet auquel on applique la méthode.

Par exemple, la méthode statique compare de la classe Integer prend deux arguments. Dès lors, une référence vers cette méthode est une fonction à deux arguments :

BiFunction<Integer, Integer, Integer> c1 =
  Integer::compare;

La méthode non statique compareTo de la même classe Integer prend un seul argument. Mais comme il s'agit d'une méthode non statique, une référence vers cette méthode est aussi une fonction à deux arguments :

BiFunction<Integer, Integer, Integer> c2 =
  Integer::compareTo;

Une seconde variante de référence à une méthode non statique permet de spécifier le récepteur. Avec cette variante, la lambda a le même nombre d'arguments que la méthode. Par exemple, une fonction permettant d'obtenir le n^e caractère de l'alphabet (en partant de 0) peut s'écrire :

Function<Integer, Character> alphabetChar =
  "abcdefghijklmnopqrstuvwxyz"::charAt;

ce qui est équivalent à, mais plus concis que :

Function<Integer, Character> alphabetChar =
  i -> "abcdefghijklmnopqrstuvwxyz".charAt(i);