Devoxx 2009 s'est tenu comme chaque année à Anvers les 18, 19 et 20 Novembre. Octo était présent pendant cet évènement important.
Le but de ce billet en deux parties, est de revenir sur les thèmes phares de cet évènement, de les synthétiser et d'apporter un regard critique.
Les thèmes qui seront abordés sont :
Voici donc la seconde partie de notre billet.
Ce sont des tendances nettement visibles à Devoxx : Java évoluera à la fois dans le sens de la productivité et de la simplicité. Java est désormais une plateforme d'exécution de nombreux langages, et ces langages influencent également le langage Java lui-même. Tout ceci s'illustre à Devoxx par les sessions sur Groovy et Scala, par les projets Coin et Lombok, et bien sûr par Java EE 6.
Groovy, Scala, Clojure... ces langages évoqués à Devoxx tournent sur une JVM et ce ne sont pas les seuls. Nous ne détaillerons pas ici les différents besoins auxquels ces langages répondent, car cela mériterait plusieurs articles.
Ces langages s'intègrent le plus souvent très bien avec Java: en étant capables d'utiliser des API Java existantes, ou en s'intégrant à l'intérieur d'applications Java par exemple sous forme d'un JAR.
Groovy et Scala étaient à l'honneur à Devoxx. Parlons également de Clojure, qui a des capacités intéressantes pour programmer des algorithmes parallélisés (notamment la gestion d'une Software Transactional Memory). L'avantage est que ces capacités sont intégrées dans le langage, mais ce langage est basé sur LISP, dont la syntaxe reste un peu déroutante pour le développeur Java.
Les langages tels que Groovy ou Scala intègrent des concepts pour le moment absents du langage Java et issus de la programmation fonctionnelle, tels que les closures. Ils bénéficient également souvent d'une syntaxe plus légère et plus productive que Java sur certains points, comme sur la manipulation des structures de données de type collection et map, ou encore sur l'accès aux propriétés d'un objet (getters/setters « implicites »).
Une chose est sûre : ces langages influencent beaucoup le langage Java. Mark Reinhold, Principal Engineer chez Sun, a en effet annoncé qu'il y aura bien des closures dans Java 7, dont la syntaxe devrait ressembler à cela: http://docs.google.com/Doc?id=ddhp95vd_6hg3qhc
La tendance à l'évolution du langage est également visible par le projet Coin, dont plusieurs évolutions sont empruntées aux langages précédemment mentionnés.
Joseph D. Darcy nous rappelle les changements qui seront apportés au langage dans le cadre du JDK7 et au delà. Tout d'abord, clarifions bien les choses : Coin est en cours d'implémentation dans OpenJDK7 mais il ne faut pas confondre le JDK7 avec JavaSE 7. En effet, tout cela n'est pas pour l'instant officiellement spécificié. Il faudra donc attendre un certain temps (probablement 2011) avant de voir ces évolutions spécifiées dans JavaSE7 et bénéficier des implémentations de Java que vous allez utiliser dans votre enterprise pour faire tourner vos serveurs d'applications.
L'équipe a reçu beaucoup de propositions de changement de la part de la communauté Java. Joseph D. Darcy nous explique que le choix des changements à retenir a été guidé par des principes assez conservateurs : il s'agit en effet d'être certain de n'introduire aucune régression dans l'ensemble de code existant.
Les changements qui sont déjà implémentés dans OpenJDK 7 Milestone 5 téléchargeable aujourd'hui:
Les changements implémentés « demain »:
Voir les détails sur le blog de Joseph: http://blogs.sun.com/darcy/entry/project_coin_final_five. Pour vous faire une idée plus précise de ces évolutions, voici un lien qui comporte des exemples de code. Ces évolutions sont très positives pour la simplicité et la productivité des développements, et il est très encourageant qu'elles soient concrètement implémentées dans OpenJDK, même si elles peuvent sembler décevantes à côté de ce que l'on sait faire dans d'autres langages sur la JVM comme par exemple Groovy.
Il faut voir ces langages comme un complément et pas comme un remplacement. En effet, étant donné que ces langages s'intègrent souvent très bien dans votre application Java, vous pouvez utiliser ces langages dans vos applications afin de profiter de leurs forces (closures, programmation fonctionnelle...). N'oubliez pas : la JVM est désormais une plateforme multi-langages.
Lombok est très différent de Coin dans son approche. En effet, il ne s'agit pas d'une modification du langage Java, et son approche est plus aggressive.
Lombok est un projet open source dont l'objectif est de simplifier le développement en améliorant la lisibilité du code en générant automatiquement un certain nombre de parties de code récurrentes. Il permet par exemple de générer automatiquement les getters, setters, equals et hashCode etc. par simple ajout d'une annotation sur la classe. Les IDE permettent également de générer ces méthodes, mais l'avantage de Lombok est que le code généré est invisible dans le code source, ce qui améliore la lisibilité.
Lombok est particulièrement adapté aux classes dont le rôle principal est d'être une structure de données, comme par exemple les classes du modèle de domaine persistées en base de données. Mais l'équipe prévoit des annotations qui permettent d'implémenter également de l'automatic ressource management dans le même esprit que Coin.
Je vous laisse découvrir des exemples de code dans la vidéo de démonstration ici : http://projectlombok.org/ Le principe de Lombok est intéressant en termes de productivité et de simplification, c'est un projet à surveiller.
Malheureusement le refactor n'est pas encore supporté. En effet, en cas de renommage d'un attribut, on ne bénéficie plus des capacités de l'IDE à répercuter automatiquement tous les appels aux getters/setters, contrairement au cas où ces méthodes sont générées par l'IDE. A noter que le besoin de génération automatique de getter/setter mène à une question : tous les attributs d'une classe doivent-ils vraiment être systématiquement privés avec des getters/setters passe-plat ? C'est un débat ouvert...
Ce thème s'est avéré sous-représenté cette année à Devoxx (4 sessions sur 62). Depuis le refroidissement du milieu IT pour ce sujet (voir la quantité d'articles titrés "SOA is dead") il ne fait plus bon parler de SOA ! Je pense davantage à une auto-censure plutôt qu'a une réelle baisse d'activité sur ces architectures et les technologies associées, les problématiques d'intégrations de système sont et seront toujours bien présentes. Pour s'en rendre compte, il n'y a qu'a jetter un oeil à la liste des projets Apache les plus populaires où Camel, ActiveMQ, CXF ou encore ServiceMix sont en très bonne place. C'est justement ce que faisait remarquer James Strachan lors de sa présentation sur FUSE, un ESB basé sur ces composants opensource (au passage, il est "juste" committer actif sur l'ensemble de ces 4 projets). Cette session, faute de temps -car c'est un passionné qui aime parler de ses projets !- s'est résumée à la présentation de Camel, un framework d'intégration permettant d'appliquer la plupart des patterns exposés dans l'excellent ouvrage "Enterprise Integration Pattern". Camel propose de spécifier l'intégration à partir d'un DSL Java, d'un fichier de configuration Spring, ou encore de Scala (version la plus concise et expressive). Un des point noir des projets d'intégration est la maintenance de la documentation lors des évolutions. Camel y répond élégamment par un plugin Maven permettant de générer cette documentation sous forme graphique.
Seconde présentation à laquelle nous avons pu assister sur ce sujet : celle de Nicolai Josutti exposant son retour d'expérience sur différents projets SOA. Son discours n'adressait pas la technique mais bien le point crucial de ces projets : leur adoption et leur organisation. Il y proposait une approche collaborative de conception des contrats de service, autours de deux repository verticaux : un pour la conception fonctionnelle, alimenté par les différents acteurs au moyens d'outils comme MagicDraw ou Rose, et un second orienté intégration à partir duquel étaient générées les implémentations à destination des client et fournisseurs de services. Il a évidemment insisté sur l'automatisation des processus de génération et de test, et sur la documentation des contrats de service. Le format WSDL étant par exemple très pauvre sur ce point.
Dans cette session, Atlassian a présenté l'intégration de gadgets OpenSocial dans ses produits. En préambule, le speaker nous rappelle a juste titre que le quotidien d'un développeur "a tout de social" : il interagit avec d'autres développeurs, fait partie d'une tribu (équipe), crée des taches ou bug, commente ces taches, communique sur ce qu'il est en train de développer, etc.
Un gadget au standard OpenSocial, initialement poussé par Google et repris par d'autres sites comme LinkedIn par exemple, peut s'afficher dans tout conteneur compatible comme confluence, jira, gmail ou encore iGoogle, on peut adresser plus facilement plusieurs populations. Imaginons par exemple un gadget indiquant le nombre de bugs ouverts sur un projet. Les utilisateurs quotidiens de JIRA (développeur, QA) vont pouvoir composer leur propre dashboard avec ce composant parmi d'autres. Le manager (grand consommateur de GMail !) va pouvoir intégrer à sa messagerie cet indicateur à côté de ses contacts.
Je pense que ce qui est intéressant est de faire communiquer les applications Atlassian ensemble pour faire des rapports croisés basés sur des informations venues de plusieurs applications Atlassian. Le côté collaboratif, avec la possibilité de les intégrer aux wiki de l'entreprise est intéressant également. Cela me fait penser à la suite Team System dans le monde .Net, qui offre déjà ça. L'intégration d'OpenSocial aux produits Atlassian en est à ses débuts, le speaker nous a invité à se renseigner et même participer à cette adresse : http://www.atlassian.com/opensocial/.
Présentation de la méthode pomodoro. Chez Octo, nous sommes nombreux à avoir expérimenté pomodoro depuis un bout de temps de la façon suivante : Déroulement :
Important :
Nous avons noté que cette méthode nous permettait de réduire le nombre de tâches dans le tableau des tâches à faire, puisque qu'on avance verticalement et qu'on limite les interruptions et les switchs de tâches, ce qui est plus efficace.
Les conférences internationales sont d'excellents thermomètres pour prendre la température d'un éco-système et de sa communauté. Cette édition de Devoxx nous a permis de récolter les tendances actuelles et de sentir les évolutions futures.
Java : un langage, une plate-forme... un écosystème Java a dépassé depuis quelques années le stade de simple langage pour s'imposer en tant que plateforme. Il a marqué une étape supplémentaire en ancrant aujourd'hui davantage son rôle dans un éco-système plus large, contenant des avancées qui ne se limitent pas à Java lui-même. Présentées tout au long de Devoxx, ces avancées sont technologiques (cloud computing, client évolué HTML5 ou Flex, ...) méthodologiques (mouvement agile, applications modulaires, ...) mais aussi sociologiques. (voir la keynote de "Uncle Bob")
Nous vous avons restitué dans cet article un résumé des keynotes qui font les moments forts de cet événement, ainsi que notre analyse sur les principaux thèmes représentés. Deux articles ne sont évidemment pas suffisant pour couvrir la richesse de ces 3 jours de conférences et si vous restez un peu sur votre faim, nous vous conseillons vivement de participer aux prochaines éditions !
Meriem Berkane, Julien Jakubowski et Sébastien Guerlet