2ème journée à SpringOne 2GX : Groovy est partout !

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

Deuxième journée de SpringOne 2GX, beaucoup plus dense que la première. On commence dès 8h30 pour terminer à 22h00, avec assez peu de temps de pause. Etant speaker aujourd’hui, j’ai dû par conséquent louper une session, mais comme vous pouvez le constater j’ai quand même beaucoup d’informations à partager !

“Groovy est partout”

La phrase n’est pas de moi, ni même de Guillaume Laforge, mais d’Adrian Coyler, le CTO de Pivotal (et ancien CTO de SpringSource), pendant la keynote de fin de journée.

En effet, les sessions sur Groovy et Grails sont littéralement prises d’assaut : je n’ai pas pu assister à la conférence sur Grails 3, faute de place ! Et ce n’est pas le seul exemple. Cela s’explique par plusieurs phénomènes :

• Il est clair que Groovy et Grails sont très populaires parmi les développeurs présents
• Le support clair et concret de Groovy dans Spring 4 attire également les développeurs Spring
• Les projets Spring Boot et Spring Reactor, très populaires tous les deux, ont des liens forts avec Groovy et Grails

Enfin, et je sais que cela ne va pas faire plaisir à tout le monde (y compris chez Ippon), mais Spring Roo est en fin de vie. Avec le départ de Ben Alex, le projet n’a plus de sponsor en interne et n’est plus activement poussé par la société. Et quoi que SpringSource ait toujours affirmé le contraire, Spring Roo était perçu par tous comme un concurrent de Grails.

Ce succès mérité est assez tardif, Groovy fêtant ses 10 ans cette année, et G2One ayant été racheté par SpringSource il y a 4 ans.

Certains y voient également une réponse à Play + Scala, car les deux couples “framework MVC dynamique + langage alternatif sur la JVM” se ressemblent.

Quoiqu’il en soit, il est clair que Groovy fait une entrée en force dans Spring 4, et que cela plaît à beaucoup de monde. Bravo donc à l’équipe Groovy, qui comprend pas mal de Français !

Spring 4 et Java 8

Juerguen Hoeller a présenté les nouveautés de Spring 4 en détail, en insistant en particulier sur l’arrivée de Java 8. Comme d’habitude avec Juergen, une session très technique avec une connaissance parfaite de son sujet !

Voici les points qui m’ont le plus marqué :

• Le JDK 8 “developer preview” vient juste de sortir (Septembre 2013), avec beaucoup de retard sur les dates d’origine, et nous sommes encore loin d’une livraison en version stable de Java 8 (prévue pour Mars 2014). Cependant, Spring 4 supporte déjà les nouveautés du JDK 8, et Juergen nous recommande de migrer sur Spring 4 aussi rapidement que possible (Spring 3.2 est d’ailleurs déjà en mode “maintenance”).
• Développer avec Java 8 peut être compliqué, en particulier si vous utilisez Eclipse (qui ne le supporte pas encore). C’est pour cette raison que Juergen utilise Intellij IDEA : la quasi totalité des développeurs Spring l’utilisent également, et je ne peux également que vous le conseiller (cela fait des années que je n’utilise plus que ça)
• Spring 4 c’est également une mise à jour des librairies tierces, de type Hibernate, Quartz, Ehcache… De manière générale les versions minimales de toutes ces librairies datent de mi-2010
• Le support de Groovy, dont nous avons déjà parlé, inclut des modifications dans l’AOP (pour prendre en compte les appels aux objets Groovy), ainsi que la possibilité de définir des beans en Groovy
• Les lambdas permettent de simplifier un grand nombre d’API existantes, en particulier toutes les templates (JdbcTemplate, JmsTemplate, TransactionTemplate, etc…). La syntaxe peut paraître un peu bizarre au début, mais c’est juste une question d’habitude (vous souvenez-vous de l’arrivée des generics ? C’était la même chose)
• La possibilité de définir des configurations de beans “conditionnelles”, plus puissantes que ce que l’on pouvait déjà faire avec les profils
• Le support des Websockets et des appels REST asynchrones

La migration vers Java 8 a eu des impacts intéressants, que vous aurez peut-être également dans vos applications : l’algorithme permettant de gérer les hash dans les HashMap et HashSet a changé, ce qui a causé de nombreux bugs (en particulier dans les tests, mais également dans du code de production). Guillaume Laforge m’a confirmé avoir eu les mêmes soucis en Groovy.

Le projet Reactor

Reactor est un nouveau projet de Pivotal, qui permet de coder des applications “réactives”. Il s’agit de pouvoir envoyer des messages à un dispatcher, qui est capable de les envoyer extrêmement rapidement aux composants qui sont abonnés à ce message. Vous pouvez ainsi travailler facilement en mode asynchrone, ce qui est traditionnellement un problème dans les applications Java EE.

Il y a plusieurs types de dispatchers, le plus rapide permettant de traiter 15 millions de messages/secondes sur un portable, ainsi que plusieurs manières de gérer ses threads ou les buffers de messages.

Au final, Reactor va avoir deux utilisations distinctes :

• Reactor devrait faciliter les architectures asynchrones au sein d’outils tels que Spring XD, Spring Boot, etc… Ce sera alors un outil interne que l’on n’utilisera pas directement
• Reactor pourra aussi être utilisé tel quel dans les applications, sachant que sa configuration et son utilisation sont vraiment simples. Pour information, Reactor ne dépend pas de Spring, et pourra donc être utilisé dans toute application Java

D’autre part, la conférence sur Reactor m’a fait découvrir trois outils que je ne connaissais pas :

• RxJava qui est un projet similaire réalisé par Netflix. Si vous avez suivi mon travail sur Tatami, vous devez savoir que je suis très fan des outils proposés par Netflix, qui sont de grands utilisateurs de Cassandra. Un projet à regarder de près, donc.
• Java Chronicle qui permet de stocker des messages très rapidement, et qui viendrait donc en complément de Reactor afin de persister les messages.
• MillWheel qui est le système utilisé par Google pour gérer leurs flux de données de manière ultra performante

Spring XD

Spring XD m’a beaucoup surpris par son niveau d’aboutissement. Il s’agit d’une plateforme complète vous permettant de faire tourner vos services de batch, et qui s’appuie sur :

• Spring Integration
• Spring Batch
• Une console graphique très bien faite : Mark Pollack a parlé d’un relooking de la console d’admin de Spring Batch, c’est franchement bien plus que ça !
• La possibilité de plugger des services comme Redis ou Hadoop pour stocker vos données ou exécuter vos jobs
• Un shell vous permettant de commander l’ensemble

J’ai ainsi pu voir une démo où l’on codait en quelques commandes à la console une application permettant de récupérer tous les derniers statuts de Twitter, de les agréger dans Hadoop, et d’afficher un nuage des tags les plus utilisés. Impressionnant de pouvoir aussi facilement utiliser Hadoop !

Pour rappel, Spring XD se trouve dans “Spring iO execution”, au même titre que Spring Boot ou Grails. C’est donc bien un runtime, mais dédié aux batchs et au “Big Data”.

Spring Batch et la JSR 352

Comme vous le savez si vous lisez le blog d’Ippon, Spring Batch a “fortement inspiré” la nouvelle JSR “Batch” présente dans Java EE.

Cependant, voici ce que vous ne savez sans doute pas :

• La JSR s’est tellement “inspiré” que la documentation de JSR est un simple copié/collé de la documentation de Spring Batch
• En conséquence, la seule implémentation existante de cette JSR, c’est Spring Batch lui-même : donc quand vous utiliserez cette JSR “standard”, vous ferez en fait du Spring Batch
• La JSR est nettement moins complète que Spring Batch : comme avec toutes les JSRs, il semble qu’il y ait eu quelques tensions, ce qui a eu des impacts sur ce qui est fourni dans la JSR. Vous aurez donc moins de fonctionnalités : à titre d’exemple, j’ai pu voir une application qui faisait 800 lignes de code avec la JSR, et qui n’en faisait plus que 500 avec Spring Batch
• Toujours en comparaison de la JSR : de manière très surprenante, elle ne supporte qu’une configuration XML, alors que Spring Batch possède également une configuration “pure Java”. Si vous voulez une configuration “sans XML”, il vous faudra donc également passer directement par Spring Batch

Testez vous-même Cloudfoundry

Terminons par un peu de code amusant. Cloudfoundry propose 60 jours gratuits, avec 2 Gigas de RAM, afin de tester leur plateforme.

Il vous suffit pour cela de :

• Vous connecter sur http://run.pivotal.io pour obtenir un compte
• Installer l’extension “Cloud Foundry” dans STS (la version d’Eclipse développée par Pivotal)

Ensuite, rien de plus facile que de développer votre application et de l’héberger dans le Cloud.

La console et les services proposés font beaucoup penser à Heroku et à Cloudbees : si vous avez déjà utilisé l’une de ces plateforme, vous ne serez pas dépaysés.

J’ai ainsi pu déployer mon premier “Hello world” en quelques minutes à peine : http://yakjulien.cfapps.io/ – pour information, il y a des blagues sur les Yaks à SpringOne à cause de l’expression “shave a Yak”.

La plateforme semble donc assez simple à prendre en main, avec des caractéristiques intéressantes par rapport à ses concurrents Heroku et Cloudbees :

• Elle est Open Source, et disponible sur Github : https://github.com/cloudfoundry
• Il y a déjà plusieurs hébergeurs qui proposent CloudFoundry, en dehors de Pivotal : vous n’êtes donc pas bloqués sur un hébergeur donné
• Elle supporte des “build packs”, qui lui permettent d’être multi-langage et multi-framework. Vous pouvez donc faire du Spring ou du Java EE (avec Webshpere), mais également du node.js ou du PHP
• Son système de “binding” d’un service (= une base de données) à une application m’a paru plus intelligent. Pour une application Spring, par exemple, CloudFoundry est capable de configurer automatiquement le Bean gérant votre DataSource, ce que je trouve très pratique et que je n’ai pas vu ailleurs.

A demain pour une nouvelle journée à SpringOne 2GX !