Plaisanterie mise à part, cet article à été rédigé en 2007, à l’heure actuelle les closures ont été descopées de Java 7. (Faute d’avoir trouvé un consensus sur leur implémentation). Elles sont en revanche disponibles dans Groovy.

Yann : le code Java produit par le programmeur n’a pas attendu les génériques pour être illisible, il en sera de même avec les closures ; c’est le programmeur qui rend un code illisible.

Un « Google Tech Talk » donné par Neal Gafter sur les closures : http://www.youtube.com/watch?v=0zVizaCOhME

Je suis d’accord pour dire que les Generiques manquaient : les (cast) à tour de bras n’étaient pas dans la philosophie de simplicité recherchée par Java. En revanche, le code généré devient de plus en plus illisible… et nuit aux objectifs précités.

L’introduction des closures me parait une erreur: oui, cela réduit le nombre de lignes de code. Non, cela ne simplifie pas la lisibilité. Non, cela ne favorise pas Java.

Je pense que les closures ne sont qu’un signe de faiblesse de Java qui succombe au lobbying des supporters de Ruby ou des outils de scripting qui permettent de coder souvent en moins de lignes… mais au détriment de la lisibilité, de la simplicité.

A moins de ne vouloir chercher l’ajout d’une nouvelle rubrique dans nos documents de normes de développement : « Fonctionnalités Java à ne pas utiliser : closures,… » ?

Yann

List<String> l = new ArrayList<String>();

et les créateurs d’API, qui maîtrisent les subtilités de la syntaxe et des wildcards pour écrire ce type de code (extrait de java.util.Collections) :


public static <T extends Comparable<? super T>> void sort(List<T> list) {
   ...
}