Catégorie: Closure/Lambda

Comme pour le JDK7, les premiers builds en "Developer Preview" du JDK8 sont disponible depuis quelques temps à l'adresse habituelle : http://jdk8.java.net/download.html

Mais pour l'instant, ces builds s'avèrent peu intéressant pour le commun des développeurs, du fait qu'ils se contentent principalement d'intégrer des correctifs sans "grosses" nouvelles fonctions ou APIs. Mais le projet Lambda a publié une autre "Developer Preview" plus intéressante : elle ne prend pas le dernier build du JDK8 mais elle y intègre le support des expressions lambda et des fonctionnalités qui y sont apparentées : http://jdk8.java.net/lambda/

En clair, c'est ce qu'il vous faut si vous voulez jouer avec les expressions Lambda...

» Lire la suite!

Le groupe de travail du projet Lambda a pris une décision concernant la syntaxe des lambdas de Java SE 8 : Syntax decision (en anglais dans le texte).

C'est donc la syntaxe de C# qui sera reprise (dans les grandes lignes - des détails pourraient encore être modifiés).

Cette syntaxe se décompose en deux parties, séparées par une flèche =>

• La partie gauche comporte la signature de la méthode, avec le nom des différents paramètres (et éventuellement leurs types).
• La partie droite comporte soit une simple expression, soit un bloc de code des plus standard (entre accolades donc)

Exemples :

  x => x + 1 
  (x) => x + 1 
  (int x) => x + 1 
  (int x, int y) => x + y 
  (x, y) => x + y 
  (x, y) => { System.out.printf("%d + %d = %d%n", x, y, x+y); } 
  () => { System.out.println("I am a Runnable"); }

Un choix "par défaut" car aucune autre proposition ne s'est vraiment imposée. Il est donc préférable d'opter pour une syntaxe existante et connue...

Ce n'est pas nouveau, mais je n'ai pas eu le temps d'en parler (il faut dire que ça faisait longtemps que je n'avais plus bloggé).

[edit 14/11/2011] Il semblerait que la flèche double ( => ) ait été abandonné au profit de la flèche simple ( -> )

Petit à petit le projet Lambda suit son cours, et le brouillon des spécifications comment à bien s'étoffer.

En fin de semaine dernière, Alex Buckley a publié une nouvelle version de ce brouillon dans la mailling-list, que l'on peut retrouver ici : Project Lambda: Java Language Specification draft version 0.1.5.

S'en est suivi plusieurs discussions, dont un débat sur la syntaxe d'appel d'une expression lambda.

» Lire la suite!

Mark Reinhold a publié au nom de Sun la première publication d'une proposition sur les expressions lambda. Mais elle se révèle pour le moment relativement succincte et s'apparente plus à une présentation sommaire des possibilités que cela offrirait qu'à une réelle proposition détaillée et précise comme cela pouvait être le cas des précédentes propositions (CICE, FCM ou BGGA).

Mais le gros problème vient du fait qu'elle ne semble pas faire l'unanimité !

En fait cette proposition fait suite à la celle de Neal Gafter et Peter von der Ahé, "Closure for Java", qui semblait faire le consensus, et que l'on imaginait facilement qu'elle servirait de base de travail aux closures de Java 7.

Or cette proposition vient d'être complétée d'une partie 0.6b qui réintègre les structures de contrôle... alors que cela ne semble pas du tout être la direction prise par la proposition de Mark Reinhold...

En fait on dirait que ces deux propositions évolue en parallèle, comme en témoigne les deux listes de diffusion : lambda-dev pour la proposition de Mark Reinhold supporté par Sun, et closures-dev pour la proposition de Neal Gafter et Peter von der Ahé (tous deux "anciens" de chez Sun, travaillant désormais respectivement chez Microsoft et Google).

Bref difficile d'y voir clair là dedans...

C'est fait, le projet Lambda est né de la volonté d'intégrer un système de closures, que l'on nommera désormais "expressions lambda".

On y retrouve donc une liste de diffusion mais surtout un prémice de la proposition : Project Lambda : Straw-Man Proposal.

On y retrouve bien sûr le détail des fonctionnalités de base dont j'ai déjà parlé plusieurs fois sur ce blog : les expressions Lambda, les types Fonction et les règles de conversion vers les types SAM.
D'autres sections restent vides, comme la transparence des exceptions ou les références de méthodes, mais sont bel et bien prévues dans la proposition (il s'agit toujours d'un document de travail).

Enfin, on dispose de plus d'information quand à l'accès aux variables, mais surtout on y découvre l'intégration des méthodes d'extensions !

Du coup j'en profite pour mettre à jour le tableau comparatif que j'avais publié dans un billet précédent :

» Lire la suite!

Tel est la question que l'on peut se poser après l'annonce surprise de l'intégration des closures dans Java 7.

  // function expressions 
  #(int i, String s) { 
    System.println.out(s); 
    return i + str.length(); 
  } 
 
  // function expressions 
  #(int i, String s) (i + str.length()) 
   
  // function types 
  #int(int, String) 

Stephen Colebourne a fait un résumé des fonctionnalités des différentes propositions de closures, en les reliant avec le peu d'information obtenu lors de la conférence Devoxx et à la nouvelle proposition de Neal Gafter : Closures for Java 0.6a, qui est présenté par tous comme un document de travail tentant de faire le consensus de chaque proposition.

Voyons voir cela de plus près...

» Lire la suite!

Originellement prévu pour février, Java 7 est reporté à septembre 2010. Bien que cela ne soit pas la cause du report (le JDK 7 milestone 5 qui aurait dû être une version "feature-complete"), il semblerait que les Closures fassent leur grand retour. Après de multiples débat et plusieurs propositions,et après avoir été abandonnés et reporté à plus tard, elles sont bel et bien de nouveaux d'actualités pour Java 7 !

Peu d'info pour le moment mis à part une présentation lors des conférences de DEVOXX, mais il semblerait qu'on opte pour un mixte entre la très complète proposition BGGA, et la plus concrète FCM.

Rien d'officiel, mais la proposition BGGA a été mise à jour et simplifié de certaines éléments (suppression de la notion d'unrestricted-closure, les structures de contrôle sont déplacées dans une spécification propre) tout en adoptant la syntaxe défini par la proposition FCM.

De plus le nom des auteurs de FCM apparait pour la première fois dans les crédits de la proposition BGGA. Arriverait-on à un consensus ?

A noter également que ce report pourrait permettre une réévaluations de certaines des propositions refusées par le projet Coin (on parle notamment du multi-catch).

Après BGGA et CICE, voici une présentation de la proposition de closures FCM qui se place exactement entre les deux précédentes : à la fois plus simple que BGGA mais également plus complète que CICE.

FCM se présente comme un compromis entre les deux, en proposant une approche plus simple sans pour autant trop perdre de possibilités.

De plus, tout comme "BGGA", la proposition "FCM" propose également un prototype sur lequel je me suis basé dans cet article (FCM-2008-02-25.zip), mais malheureusement il n'implémente pas toutes les fonctionnalités de la proposition...

» Lire la suite!

Les Closures style BGGA sont extrêmement complète, mais apporte également leurs lots de complexité. De ce point de vue là, la proposition CICE prend le problème à contre pied et propose une implémentation la plus simple possible.

D'ailleurs la documentation donne le ton dès le début, en titrant "Closures without Complexity"...

» Lire la suite!

Lorsque j'ai commencé à écrire la série de billet "Où va Java ?" conçernant Java 7, j'avais en tête de faire un billet récapitulant les différentes propositions de Closures et leurs spécificités. Malheureusement le temps m'a manqué et je n'ai jamais pu finir ce billet...

Pour rappel, une closures représente un "bloc de code", qui peut être manipuler comme un objet. A l'heure actuelle l'utilisation de classe anonyme est ce qui s'en rapproche le plus (avec une syntaxe assez lourde toutefois). L'objectif des Closures étant d'utiliser une syntaxe plus concise.

Il existe quatre grosses propositions de Closures pour Java :

• "CICE" (spec), par Bob Lee, Doug Lea et Josh Bloch.
• "FCM" (spec), par Stephen Colebourne et Stefan Schulz.
• "C3S" (spec), par Howard Lovatt.
• "BGGA" (spec), par Gilad Bracha, Neal Gafter, James Gosling et Peter von der Ahé.

Aujourd'hui, et malgré le fait qu'il n'existe pour le moment aucune JSR ni information officiel quand à une éventuelle intégration des Closures dans Java SE 7, cette idée de comparaison me semble bien moins pertinente : la proposition "BGGA" me semble la plus complète. De plus elle a su évoluer afin de s'enrichir des bonnes idées des autres propositions (comme les "Method references" de FCM). Si les Closures se retrouve un jour intégré dans Java, il y a de forte chance que ce soit à partir de cette proposition.

Enfin, "BGGA" propose d'ore et déjà un prototype fonctionnel (closures.tar.gz) qui permet de tester "en vrai" les différentes fonctionnalités de la proposition. Je vais donc me contenter de présenter les Closures façon "BGGA"...

» Lire la suite!