3ème journée à SpringOne 2GX : interviews de Guillaume Laforge et Stéphane Maldini

(si vous voulez lire les autres articles liés à SpringOne sur le blog d’Ippon Technologies, suivez le tag #springone)

Cette 3ème journée a été l’occasion pour moi de voir plusieurs conférences intéressantes, que je vais vous présenter brièvement.

Peter Ledbrook a présenté les patterns d’architecture que l’on pouvait réaliser en Grails : il a ainsi présenté le DDD, CQRS, les applications single Web page, le besoin de faire des requêtes asynchrones, les systèmes de messages, etc. Ses slides étant en ligne, je vous laisse les lire directement :

Mais plutôt que de faire un 3ème post vous décrivant les conférences, cet article est l’occasion d’interviewer deux des autres français qui étaient speakers à SpringOne 2GX, Guillaume Laforge et Stéphane Maldini. Ce sont des interviews volontairement “tous publics”, afin de vous présenter les projets sur lesquels ils travaillent.

A gauche Guillaume Laforge (avec le t-shirt Groovy), à droite Stéphane Maldini (avec le t-shirt Grails)

Interview de Guillaume Laforge

Bonjour Guillaume, est-ce que tu peux te présenter brièvement ?

Je dirige le projet Groovy, qui est un langage dynamique pour la JVM.
Je travaille chez Pivotal, la spin-off de SpringSource, VMware et EMC.
Et je suis un des membres du podcast des Cast Codeurs.

Quelle est la roadmap de Groovy pour ces prochaines années ?

Nous allons très prochainement sortir Groovy 2.2, avec par exemple une fonctionnalité pour pouvoir utiliser les closures de Groovy là où on aurait utilisé une class anonyme interne dans le même esprit que ce que fait Java 8 avec les lambdas. Mais on va un peu plus loin qu’avec les lambdas, dans le sens où ça fonctionne également avec des classes abstraites et pas seulement avec des interfaces.

Nous ajoutons aussi une nouvelle transformation de code déclenchée par l’annotation @Memoized qu’on met sur une méthode, qui permet de mettre en cache les valeurs de retour de l’invocation de cette méthode. Cela permet d’éviter de re-calculer des résultats qui prendraient beaucoup de temps de CPU. Plus d’autres fonctionnalités pratiques, des améliorations des outils comme “groovysh” (la ligne de commande Groovy).

Au delà de Groovy 2.2, on devrait sortir une version 2.3 puis 3.0. Dans la version 2.3, on est en train d’expérimenter avec la notion de “trait”, qui permet de mixer du comportement dans des classes (on peut même faire de l’héritage multiple). Par ailleurs, nous sommes en train de travailler sur une toute nouvelle documentation et un nouveau site Web qui permettra aux utilisateurs de mieux s’y retrouver et d’obtenir l’information pertinente qu’ils recherchent sur telle ou telle fonctionnalité de Groovy.

Après, pour Groovy 3, c’est pour un horizon déjà plus lointain (en tout cas, peu après la sortie de Java 8 / JDK 8), où l’on regarde comment réimplémenter le runtime dynamique de Groovy pour le rationaliser et améliorer ses performances, comment faire évoluer la grammaire du langage avec une version plus récente de Antlr (l’outil que l’on utilise pour décrire la grammaire du langage), et puis comment adapter Groovy à Java 8 et JDK 8 pour supporter les nouvelles fonctionnalités comme les lambdas, les annotations répétées, les nouvelles APIs de date et calendrier, etc.

Groovy est au coeur de Spring 4, quelles sont les nouveautés disponibles pour les développeurs Spring, qui ne connaissent pas Groovy ?

Avec le développement de Groovy et de Grails, nous avons rencontré différentes petites choses qui pouvaient être améliorées dans l’utilisation de Spring à partir de Groovy. On a travaillé avec l’équipe Spring pour remonter ce feedback, afin de faire en sorte que Spring sache prendre en compte les spécificités de Groovy.

Outre ces petites améliorations, il faut aussi noter la naissance de Spring Boot, une nouvelle approche pour développer plus facilement des applications Spring, prenant l’approche de la “Convention over Configuration”, qui s’occupe de vous lancer un conteneur comme Tomcat pour faire tourner votre application. Et surtout… une très belle utilisation de Groovy qui permet de facilement développer des applications Spring, de manière très succinte, à tel point qu’on peut faire tenir un “hello world” Spring écrit en Groovy dans un tweet !

(cf. https://spring.io/blog/2013/08/06/spring-boot-simplifying-spring-for-everyone/)

Ce qui était sympa aussi à la conférence SpringOne 2GX cette année, c’est le gros focus sur Groovy, qui prend une place centrale dans la plateforme Spring, avec par exemple l’intégration de Groovy avec dans le framework Spring bien sûr, mais également dans Spring XD, Spring Batch, Spring Integration, dans Reactor, etc.

Les lambdas arrivent dans Java 8, qu’en penses-tu, toi qui utilise ce mécanisme depuis longtemps dans Groovy ?

J’ai des sentiments partagés sur les lambdas dans Java 8. En fait, je suis content qu’elles arrivent enfin dans Java 8, après toutes ces années, mais d’un autre côté, avec ma casquette d’implémenteur du langage Groovy, je suis embêté parce que Groovy a déjà des closures qui sont assez proches des lambdas, mais qui ont tout de même quelques différences notables. Du coup, côté Groovy, on va être obligé de supporter les closures et les lambdas à la fois !

Mais globalement, je trouve que c’est une bonne chose que les lambdas apparaissent dans Java. Et également que les lambdas soient utilisées à bon escient dans les APIs du JDK comme les collections, avec la notion de stream, etc.

Après avoir utilisé les closures de Groovy depuis 2003, je les trouve tellement utiles dans tout un tas de situations (itérer, filtrer, transformer une collection, etc.) que je pense qu’elles permettront aux développeurs Java d’écrire du code finalement plus lisible, plus orienté “fonctionnel”, et de moins programmer impérativement en pensant à ce que l’ordinateur doit faire avec nos collections plutôt que de déclarer au compilateur le but que l’on souhaite atteindre.

Interview de Stéphane Maldini

Bonjour Stéphane, est-ce que tu peux te présenter brièvement ?

Je suis Consultant “Enterprise Solutions” chez Pivotal, actuellement basé sur Londres, et contributeur Grails à mes heures perdues. Entre deux voyages j’ai demarré le projet Reactor avec Jon Brisbin (@j_brisbin).

Le projet Reactor a eu beaucoup de succès à SpringOne 2GX, peux-tu nous expliquer en quoi consiste le projet ?

Le but de ce projet est d’offrir une fondation pour les applications avec des besoins asynchrones, on parle aussi d’applications “réactives”. Java offre quelques outils intéressants pour programmer des tâches concurrentes mais on reste assez limité, malgré les derniers changements dans JDK8. Reactor est là pour aider le programmeur Java moderne a dépasser ces limites, on propose de petits outils efficaces, rapides et qui facilitent l’utilisation de librairies plutôt considérées difficiles comme LMAX Disruptor ou Java Chronicle. On trouve parmi les use-cases le développement de driver asynchrones (Couchbase travaille sur un tel driver et nous avons un driver expérimental pour Riak), le développement d’applications “Event-Driven” grâce au découplage Selector/Dispatcher/Consumer, l’ingestion de données par paquet de millions…

Reactor est portable, il ne dépend pas de Spring ou d’un langage en particulier si ce n’est Java. Pourtant nous avons d’ores et déjà une intégration avancée avec le module dédié Spring et une syntaxe séduisante via le fantastique langage Groovy. Groovy reste pour moi l’allié idéal de Reactor car même si nous introduisons des paradigmes fonctionnels, le but premier de Reactor est de démocratiser la programmation concurrente. Groovy introduit une agilité dans le modèle de programmation sans en toucher le raisonnement comme aurait tendance à le faire un langage vendu fonctionnel. Pour voir de quoi il en retourne, rien de mieux que de se rendre sur la page des micro samples et de commencer rapidement avec cet exemple https://github.com/reactor/reactor-samples/blob/master/src/main/java/org/projectreactor/samples/ReactorSamples.java#L17.

Parmi les autres plus de Reactor: Promise, Stream (Inspire par Netflix RxJava), Serveur/Client Netty, PersistentQueue, Buffers… Une vraie trousse a outils, avec ça vous êtes armés jusqu’aux dents !

Est-ce un concurrent de Akka, de Typesafe ?

Tu n’es pas le premier et probablement loin d’être le dernier à poser cette question : http://stackoverflow.com/questions/16595393/akka-or-reactor. C’est un sentiment facile à comprendre, Akka est un des frameworks asynchrones connus pour la JVM et en particulier Scala. C’est un outil très intéressant, pourtant je pense que nous poursuivons des objectifs différents : Reactor est plus proche du bus événementiel que Akka, il y a une souplesse au niveau de la stratégie de dispatching et de threading que nous apprécions dans Reactor, Jon et moi-même. C’est une des raisons qui nous a conduit a créer ce projet : pourquoi rester bloqué sur une seule manière de voir les traitements asynchrones, pourquoi coupler le producteur et le consommateur ? La même réponse s’applique a Vert.x. Je pense que le tech lead de Akka (Roland Kuhn) saisit cette différence également. Et puis nous sommes inspirés les outils asynchrones d’Erlang, le dénominateur commun a Vert.x, Akka et nous-mêmes.

Tu as également fait une conférence sur Atmosphere : quels sont les liens entre Reactor et Atmosphere, et est-ce que Reactor ne remplace pas le Broadcaster d’Atmosphere ?

Le Broadcaster est un outil intéressant dans Atmosphere, clé de voûte de la production de messages du serveur au client. Je suis un fan absolu d’Atmosphere et je vois mal comment remplacer autant d’années de dur labeur de Jean-Francois, cet homme est un héros de patience pour moi, il a réussi à apporter un dénominateur commun aux techniques de push pour Java. Je pense que les deux se complètent parfaitement, évidement il est possible de remplacer un peu de logique de dispatching serveur par une approche Reactor, mais il est indispensable de passer par les outils d’écriture et de suspension de requête d’Atmosphere. Donc concrètement, au lieu de Broadcaster.broadcast() + Handler + request.writer.write(), ça serait plutôt Reactor.notify() + Reactor.on() + request.writer.write(). Ca se vaut, je ne pense pas que les développeurs ne vont pas forcément penser à utiliser Atmosphere pour développer leur projet asynchrone générique, et c’est là que Reactor arrive.

Pour finir, voici les slides des deux préentations de Stéphane à SpringOne 2GX, sur Reactor et le “Web real-time”, avec Atmosphere