Généricité avancée

Les bases de la généricité en Java ont été introduites lors d'une leçon précédente. Il reste néanmoins trois aspects de la généricité à présenter : les bornes, les jokers et les types bruts. Avant de pouvoir les présenter, il importe toutefois d'examiner en détail la notion de sous-typage, cruciale à leur compréhension.

En Java, chaque classe, énumération et interface définit un type, et ces types sont liés entre eux par une relation de sous-typage. Cette relation de sous-typage est déterminée par la manière dont les classes et interfaces sont liées entre elles : lorsqu'une classe hérite d'une autre, son type est sous-type de celui de sa super-classe, et il en va de même pour les interfaces ; de plus, lorsqu'une classe implémente une interface, son type est sous-type de celui de l'interface.

Par exemple, le type String est un sous-type du type Object car la classe String hérite de la classe Object. De manière similaire, le type Number est un sous-type du type Serializable car la classe Number implémente l'interface Serializable.

Pour mémoire, le sous-typage est important en raison du polymorphisme d'inclusion, qui permet de substituer à une valeur d'un type T₁ donné une valeur d'un autre type T₂ pour peu que T₂ soit un sous-type de T₁. On appelle aussi cela le principe de substitution (substitution principle).

Par exemple, si une fonction prend en argument une valeur de type Number, en plus d'une valeur de ce type on peut lui passer une valeur de type Integer, Double, etc. qui sont des sous-types de Number. Ainsi, l'appel à add ci-dessous est valide en raison du principe de substitution :

Number add(Number n1, Number n2) {
  return new Double(n1.doubleValue() + n2.doubleValue());
}
add(new Integer(1), new Double(3.14));

Formellement, la relation de sous-typage est :

• réflexive, c-à-d que tout type est sous-type de lui-même,
• transitive, c-à-d que si un type T₁ est sous-type d'un type T₂ et T₂ est sous-type de T₃, alors T₁ est aussi sous-type de T₃,
• anti-symétrique, c-à-d que si T₁ est sous-type de T₂ et T₂ est sous-type de T₁, alors T₁ = T₂.

En mathématiques, une relation possédant ces trois propriétés est appelée un ordre partiel (partial order).

Comme tout ordre partiel, la relation de sous-typage Java peut être visualisée sous la forme d'un graphe dirigé dans lequel chaque type est un nœud et un arc lie le nœud d'un type à celui de ses super-types directs. La figure 1 présente un minuscule extrait du graphe des types standard Java.

A noter que lorsqu'un type T₂ est sous-type d'un type T₁, on dit que T₁ est un super-type de T₂.

Le sous-typage et la généricité interagissent de manière non triviale et parfois surprenante. Pour l'illustrer, nous utiliserons l'interface générique List ci-dessous, une version simplifiée de celle de la bibliothèque Java, ainsi que sa mise en œuvre (simplifiée) LinkedList, que l'on suppose exister.

public interface List<E> implements Iterable<E> {
  boolean isEmpty();
  int size();
  void add(E newElem);
  Iterator<E> iterator();
}

Le principe de substitution nous permet d'ajouter n'importe quel type de nombre — c-à-d n'importe quel sous-type de Number — à une liste de nombres :

List<Number> l = new LinkedList<>();
Integer i = 1;
l.add(i); // valide car Integer est sous-type de Number
Double d = 3.14;
l.add(d); // valide car Double est sous-type de Number

Pour faciliter l'ajout de tous les éléments d'une liste à une liste existante, on peut vouloir ajouter une méthode addAll à List. Une première version de cette méthode pourrait ressembler à ceci :

public interface List<E> {
  // …
  void addAll(List<E> other);
}
public class LinkedList<E> implements List<E> {
  // …
  void addAll(List<E> other) {
    for (E elem: other)
      add(elem);
  }
}

Malheureusement, cette méthode addAll n'est pas utilisable comme nous le désirerions, car l'ajout d'une liste d'entiers Integer à une liste de nombres Number est invalide :

List<Number> l = new LinkedList<>();
List<Integer> li = new LinkedList<>();
Integer i = 1;
li.add(i);
l.addAll(li); // refusé !

Ce code est refusé car, en Java, une instanciation d'un type générique n'est jamais sous-type d'une autre instanciation de ce même type générique ! Par exemple, le type List<U> n'est jamais sous-type de List<V> sauf dans le cas trivial où U = V. Nous verrons plus loin la raison de cette restriction.

Le seul moyen de rendre l'appel à addAll valide est donc de changer le type de la seconde liste pour en faire une liste de Number. Cela n'est pas très satisfaisant, car il est clairement valide d'ajouter une liste d'entiers à une liste de nombres. Il nous faudra trouver une solution !

Attention toutefois, la restriction mentionnée ne signifie pas que deux types génériques différents ne peuvent pas être liés par la relation de sous-typage. Par exemple, LinkedList<String> est un sous-type de List<String> car la classe générique LinkedList<E> implémente l'interface List<E>. Par contre, deux instanciations différentes du même type générique ne sont jamais liées entre elles par la relation de sous-typage.

Cela est illustré par la figure 2 qui montre la relation de sous-typage pour deux instanciations de List. Il est très important de noter l'absence de flèche (donc de relation de sous-typage) entre les deux instanciations de List ou de LinkedList.

Pourquoi les concepteurs de la généricité Java ont-ils choisi d'imposer cette restriction ? Pour le comprendre, admettons que List<Integer> soit un sous-type de List<Number>. Cela nous autoriserait à écrire le code suivant :

void addPi(List<Number> l) {
  l.add(3.14);
}
List<Integer> l = new LinkedList<>();
addPi(l);

Or ce code est clairement faux, car il ajoute un nombre réel — une valeur de type double, pour être précis — à une liste de nombre entiers.

Le paramètre de type F de la méthode addAll n'est pas utilisé ailleurs que dans son type. Il n'est donc pas nécessaire de le nommer, et Java permet d'utiliser dans ce cas un joker (wildcard) borné, noté ? :

public interface List<E> {
  // …
  void addAll(List<? extends E> other);
}

Cette version de addAll est totalement équivalente à la précédente, mais plus concise et donc généralement préférable.

A noter qu'il est aussi possible d'utiliser un joker sans le borner explicitement, ce qui équivaut à le borner avec Object. Par exemple, List<?> est équivalent à List<? extends Object>.

La généricité n'a été introduite que tardivement dans le langage Java, à un moment où beaucoup de code non générique avait déjà été écrit. Idéalement, tout ce code non générique aurait dû être adapté immédiatement, et la question de la compatibilité entre les deux formes de code ne se serait pas posée.

En pratique, cela n'était bien entendu pas possible, et les concepteurs de la généricité Java ont donc introduit des concepts facilitant la compatibilité entre le code générique et le code non générique. Nous ne considérerons ici que le cas du code non générique utilisant du code générique.

Lorsque la généricité a été ajoutée à Java, sa bibliothèque standard a été modifiée pour en tirer parti. Par exemple, l'interface List a été transformée en List<E>, où E représente le type des éléments de la liste. Rigoureusement, une fois cette modification faite, le type List (sans argument de type) est invalide et son utilisation devrait être refusée. Mais cela rendrait beaucoup d'ancien code invalide.

Pour éviter ce problème, les concepteurs de Java ont introduit la notion de type brut (raw type), qui est simplement un type générique utilisé sans paramètres. Dans notre exemple, List est un tel type.

La version brute d'un type interagit avec la version générique de ce même type de la manière suivante :

• une version générique peut être utilisée partout où la version brute est attendue, sans provoquer l'affichage d'un avertissement,
• la version brute peut être utilisée partout où une version générique est attendue, mais cela provoque l'affichage d'un avertissement.

Par exemple, si on passe une valeur qui a le type brut List à une méthode qui attend une valeur de type List<String>, le code est accepté avec un avertissement.

• Effective Java (3rd ed.) de Joshua Bloch, en particulier :
  • la règle 31, Use bounded wildcards to increase API flexibility sur l'utilisation judicieuse des jokers bornés,
  • la règle 26, Don't use raw types sur les types bruts et les raisons de ne plus les utiliser,
• Java Generics and Collections de Maurice Naftalin et Philip Wadler, O'Reilly Media,
• Java Generics FAQ d'Angelika Langer, une liste des questions fréquentes liées à la généricité Java, et leur réponse.