Généricité

Une cellule de chaîne est une version restreinte d'une cellule, uniquement capable de stocker une chaîne de caractères, et non pas un objet de type quelconque. La chaîne contenue dans une telle cellule lui est passée au moment de la construction, et peut s'obtenir au moyen d'une méthode nommée get.

La définition d'une classe nommée CellOfString et représentant une cellule de chaîne est triviale:

public final class CellOfString {
  private final String s;

  public CellOfString(String s) { this.s = s; }
  public String get() { return s; }
}

Une fois cette classe définie, on peut p.ex. l'utiliser ainsi :

CellOfString message = new CellOfString("Bonne année 2024");
System.out.println(message.get());

Admettons maintenant que l'on ait également besoin d'une classe de cellule capable de stocker une date d'un type Date que l'on suppose exister. Une fois encore, la définition d'une telle classe, nommée CellOfDate, est triviale :

public final class CellOfDate {
  private final Date d;

  public CellOfDate(Date d) { this.d = d; }
  public Date get() { return d; }
}

Ce nouveau type de cellule peut s'utiliser avec le précédent :

CellOfString message = new CellOfString("Bonne année ");
CellOfDate date = new CellOfDate(Date.today());
System.out.println(message.get() + date.get().year());

Les classes CellOfString et CellOfDate représentent des cellules de chaîne et de date, respectivement. Que faire si on désire également stocker de nombreux autres types dans des cellules, p.ex. des entiers, des tableaux, etc. ?

Une solution évidente serait de poursuivre sur la même voie et d'écrire une nouvelle classe cellule pour chaque cas. Cette solution, parfois nommée spécialisation, n'est toutefois clairement pas réaliste à grande échelle en raison de la (quasi-)duplication de code qu'elle implique.

En Java, il existe toutefois une autre solution, qui tire parti du fait que le type Object est un super-type de tous les autres types — sauf les types primitifs comme int ou double, nous y reviendrons. L'idée consiste à définir une classe de cellule dont l'élément a le type Object et de l'utiliser pour y stocker différents types d'objets comme des chaînes, des dates, etc. Examinons cette solution.

La classe Cell ci-dessous représente une cellule capable de stocker un objet de type Object. Elle est bien entendu très similaire aux classes CellOfString et CellOfDate, la seule différence étant le type de l'attribut contenant l'objet, et le type de retour de la méthode get :

public final class Cell {
  private final Object o;

  public Cell(Object o) { this.o = o; }
  public Object get() { return o; }
}

Au moyen de cette unique classe de cellule, il est possible de récrire le programme d'exemple donné plus haut. Malheureusement, étant donné que la méthode get a pour type de retour Object, il faut rajouter quelques transtypages qui alourdissent le code :

Cell message = new Cell("Bonne année ");
Cell date = new Cell(Date.today());
System.out.println((String)message.get()
                   + ((Date)date.get()).year());

En plus d'alourdir le code, ces transtypages ne sont pas sûrs, dans le sens où ils peuvent échouer à l'exécution si le programmeur fait une erreur et place une chaîne au lieu d'une date dans la cellule date :

Cell message = new Cell("Bonne année ");
Cell date = new Cell("2024");
System.out.println((String)message.get()
                   + ((Date)date.get()).year());

Ce programme est valide mais lève l'exception ClassCastException lors de l'exécution, au moment où il tente de transtyper la chaîne extraite de la cellule date en Date.

Cette solution basée sur le type Object, même si elle est plus réaliste que la spécialisation et était utilisée dans les premières versions de Java, n'est donc pas non plus satisfaisante : premièrement car elle implique l'ajout de beaucoup de transtypages, et deuxièmement car ces transtypages peuvent échouer à l'exécution si le programmeur commet une erreur.

Une classe pour les cellules générique (d'un type arbitraire) peut se définir ainsi :

public final class Cell<E> {
  private final E e;

  public Cell(E e) { this.e = e; }
  public E get() { return e; }
}

Cette classe est générique, et E est son paramètre de type. Il s'agit d'une variable (de type !) représentant le type de l'élément de la cellule. Dans le corps de la classe, E peut s'utiliser comme n'importe quel autre type — ou presque, comme nous le verrons plus loin.

Pour utiliser un type générique tel que Cell, il faut spécifier le type concret à utiliser pour son paramètre de type, comme dans les exemples suivants :

Cell<String>        // lire: cell of string
Cell<Date>          // lire: cell of date
Cell<Cell<String>>  // lire: cell of cell of string

On appelle ces types des instanciations du type générique Cell.

Contrairement aux cellules basées sur Object, les cellules génériques n'impliquent aucun transtypage :

Cell<String> message = new Cell<String>("Bonne année ");
Cell<Date> date = new Cell<Date>(Date.today());
System.out.println(message.get() + date.get().year());

et ne comportent pas les mêmes risques, le programme ci-dessous étant simplement refusé :

Cell<String> message = new Cell<String>("Bonne année ");
Cell<Date> date = new Cell<Date>("2024"); // interdit !
System.out.println(message.get() + date.get().year());

A noter que l'exemple plus haut peut encore être allégé, puisque les paramètres de type dans un énoncé new sont optionnels. S'ils sont omis, ils sont automatiquement inférés (c-à-d calculés) par Java. L'exemple peut donc être récrit ainsi :

Cell<String> message = new Cell<>("Bonne année ");
Cell<Date> date = new Cell<>(Date.today());
System.out.println(message.get() + date.get().year());

Attention, lorsqu'on omet ainsi les paramètres de type, il est néanmoins obligatoire de placer une paire de crochets vide (<>) après le nom du constructeur. En raison de son apparence, cette paire de crochets vide est souvent appelée le diamant (diamond).

Admettons que l'on désire maintenant ajouter une méthode pairWith à Cell permettant d'obtenir une paire dont le premier élément est celui de la cellule, et le second lui est passé en argument.

public final class Cell<E> {
  private final E e;
  // … comme avant
  public Pair<E, XXX> pairWith(XXX s) {
    return new Pair<>(e, s);
  }
}

Quel type utiliser à la place de XXX pour le paramètre de pairWith ?

Une première idée serait d'utiliser le paramètre de type E :

public final class Cell<E> {
  private final E e;
  // … comme avant
  public Pair<E, E> pairWith(E s) {
    return new Pair<>(e, s);
  }
}

Cela est toutefois bien trop limitatif, car on ne peut ainsi créer que des paires dont le second élément a le même type que celui de la cellule…

Une deuxième idée serait d'ajouter un second paramètre de type à la classe Cell :

public final class Cell<E,S> {
  private final E e;
  // … comme avant
  public Pair<E, S> pairWith(S s) {
    return new Pair<>(e, s);
  }
}

Mais il s'agit d'une mauvaise solution pour plusieurs raisons, entre autres parce qu'elle associe le paramètre de type S à la classe Cell, alors qu'il appartient clairement à la méthode pairWith.

La bonne solution consiste à associer le paramètre de type S à la méthode pairWith, ce qui peut se faire en Java. Attention toutefois, la syntaxe est assez surprenante !

public final class Cell<E> {
  private final E e;
  // … comme avant
  public <S> Pair<E, S> pairWith(S s) {
    return new Pair<>(e, s);
  }
}

Une méthode qui prend un ou plusieurs paramètres de types, comme pairWith, est dite méthode générique (generic method).

Pour appeler une méthode générique, il faut logiquement spécifier les types à utiliser pour ses paramètres de type. Là aussi, la syntaxe est surprenante au premier abord — même si elle est cohérente avec la syntaxe de définition des méthodes génériques. Ainsi, la méthode pairWith peut s'utiliser comme suit :

Cell<String> message = new Cell<>("Bonne année ");
Pair<String, Date> pair =
  message.<Date>pairWith(Date.today());
System.out.println(pair.fst() + pair.snd().year());

Heureusement, la valeur des paramètres de type des méthodes générique peut presque toujours être inférée, et on peut donc simplement écrire :

Cell<String> message = new Cell<>("Bonne année ");
Pair<String, Date> pair =
  message.pairWith(Date.today());
System.out.println(pair.fst() + pair.snd().year());

Notez que dans ce cas, il ne faut pas mettre le diamant (<>), car cela est incorrect. La raison pour laquelle le diamant est nécessaire dans les énoncés new mais interdit dans les appels de méthodes génériques est expliquée plus loin.

Pour mémoire, Java possède huit types dits primitifs (primitive types) dont les valeurs ne sont pas des objets : boolean, byte, short, int, long, char, float et double.

Malheureusement, ces types primitifs ne peuvent pas être utilisés comme paramètres de type d'un type générique. Dès lors, le code suivant est erroné :

Cell<int> s = new Cell<>(1); // interdit !

Que faire si l'on désire par exemple créer une cellule contenant un entier (de type int) ?

Une solution consiste à stocker l'entier dans un objet de type java.lang.Integer, et créer une cellule de ce type¹. L'exemple devient :

Cell<Integer> c = new Cell<>(new Integer(1));

En réalité, la construction directe d'instances de Integer au moyen de new est découragée, et il est préférable de créer l'instance de Integer au moyen de la méthode valueOf, ainsi :

Cell<Integer> c = new Cell<>(Integer.valueOf(1));

La différence entre ces deux versions n'est pas importante pour ce qui suit et peut donc être ignorée.

Lorsqu'on stocke ainsi un entier dans une instance de Integer, on dit que cet entier a été emballé (wrapped ou boxed en anglais). En plus de la classe Integer, le paquetage java.lang contient une classe d'emballage pour les sept autres types primitifs (Boolean pour boolean, Character pour char, Double pour double, etc.) A l'exception de Boolean, toutes ces classes héritent d'une super-classe abstraite commune, Number.

Bien entendu, lorsqu'on ressort le valeur emballée de la cellule, il faut la déballer (unwrap ou unbox en anglais) avant de pouvoir l'utiliser. Dans le cas des entiers, cela se fait au moyen de la méthode intValue de la classe Integer :

Cell<Integer> c = new Cell<>(new Integer(1));
int succ = c.get().intValue() + 1;

Des méthodes de déballage similaires existent dans toutes les classes d'emballage.

L'emballage et le déballage manuels étant lourds à l'usage, le code nécessaire est généré automatiquement par Java. On nomme cela l'emballage automatique (autoboxing).

L'exemple précédent peut donc également s'écrire ainsi :

Cell<Integer> c = new Cell<>(1);
int succ = c.get() + 1;

et est automatiquement transformé afin que l'entier 1 soit emballé avant d'être passés au constructeur puis déballé avant l'addition.

Admettons que toutes les cellules manipulées par un programme contiennent une instance d'une sous-classe de Number, p.ex. Integer, Double, etc.

Il devrait alors être possible d'ajouter à Cell une méthode tirant parti de cela, comme getInverse ci-dessous. Cette méthode retourne l'inverse du nombre stocké dans la cellule, obtenu au moyen de la méthode doubleValue de Number :

public final class Cell<E> {
  private final E e;
  // … comme avant
  public double getInverse() {
    return 1.0 / e.doubleValue();
  }
}

Malheureusement, cette méthode est refusée par Java ! En effet, appeler doubleValue sur l'objet e n'est valide que si celui-ci est une instance d'une sous-classe de Number. Or comme il a le type E, et que celui-ci peut-être quelconque (p.ex. String), l'appel n'est clairement pas valide dans le cas général.

Il faudrait donc avoir la possibilité de contraindre le paramètre de type E, de manière à garantir que l'objet e est une instance d'une sous-classe de Number.

Heureusement, Java offre une telle possiblité, que l'on nomme une borne supérieure (upper bound). La définition de la classe Cell ci-dessus peut être modifiée pour ajouter une telle borne à son paramètre de type E, le forçant à être une sous-classe de Number :

public final class Cell<E extends Number> {
  // … comme avant
}

Une fois cette borne ajoutée, la méthode getInverse est acceptée. Bien entendu, cela a un coût : il n'est désormais possible d'instancier le type Cell qu'avec des sous-types de Number, et un type comme Cell<String> est maintenant refusé.

Limitation 1 : la création de tableaux dont les éléments ont un type générique est interdite.

Par exemple, le code suivant est invalide :

static <T> T[] newArray(T x) {
  return new T[]{ x }; // interdit
}

Attention : seule la création (via new) de tableaux d'éléments génériques est interdite. Il est tout à fait possible de déclarer un tableau de type générique.

Bien entendu, les tableaux dynamiques (ArrayList) étant une classe générique tout à fait normale, ils ne souffrent pas de cette limitation. Seuls les tableaux primitifs du langage sont affectés.

Limitation 2 : les tests d'instance impliquant des types génériques sont interdits. Par exemple, le code suivant est refusé :

<T> void printIfStringCell(Cell<T> c) {
  if (c instanceof Cell<String>) // interdit
    System.out.println(c);
}

Limitation 3 : les transtypages impliquant des types génériques ne sont pas sûrs.

Par exemple, le code suivant ne lève pas d'exception à l'exécution, alors qu'il devrait en lever une :

Cell<Integer> c = new Cell<>(1);
Object o = c;
Cell<String> c2 = (Cell<String>)o;

Un avertissement est toutefois produit.

Limitation 4 : une classe définissant une exception ne peut pas être générique.

En d'autres termes, aucune sous-classes de Throwable ne peut avoir de paramètres de type. Par exemple, la définition suivante est refusée :

class InvalidException<T> extends Exception {}