Devoxx Belgique, la plus grande conférence Java européenne, énorme queue à l’entrée. Heureusement que je me suis procuré mon pass la veille au soir. Le programme est disponible dans le hall, des boissons et des croissants gratuits nous attendent, je dépose mon manteau au vestiaire. Les goodies ne sont pas encore arrivés, plus rien d’autre à faire que de se positionner devant la bonne salle.

Devoxx se déroule au Kinepolis d’Anvers, un grand complexe de cinémas, 18 salles en tout, dont la moitié est réservée pour la conférence. Des salles spacieuses, des sièges confortables avec une place pour les boissons devant les accoudoirs, des écrans géants, il ne manque plus que le popcorn.

Design Pattern Reloaded par Rémi Forax

Pour la première séance d’université (présentation de fond sur un sujet durant 3 heures), j’ai choisi « Design Pattern Reloaded » par Rémi Forax, professeur à la fac de Marne la Vallée, et surtout une des rock stars française du monde Java. Rémi Forax est connu pour avoir participé à l’élaboration du byte code « invokedynamic » ainsi qu’aux lambdas, et participe actuellement à celle des Modules de Java 9. La présentation reprend certains Design Patterns connus en les implémentant à l’aide de lambdas. L’utilisation de fonctions à la place des classes permet de mieux comprendre pourquoi il faut favoriser la composition sur l’héritage, pourquoi les classes abstraites publiques sont à éviter, et surtout comment certains patterns des langages fonctionnels, tels que les applications partielles, les exécutions différées ou les « higher order functions » deviennent plus simples. J’ai aussi réalisé comment l’utilisation abusive des lamdas, couplée à celle des génériques avec des wildcards, pouvait rendre un code complètement illisible. Est-ce que j’utiliserai moi-même certains de ces patterns? À voir…

Caching 101: caching on the JVM and beyond

Après un déjeuner composé de soupe et de salade (apparemment ils savaient que j’avais fait McDo la veille), je me suis positionné pour ma seconde séance de 3 heures. J’ai failli suivre celle de José Paumard sur la comparaison entre RxJava, une librairie fonctionnelle pour Java qui existait bien avant Java 8, et la librairie stream de Java 8. Mais j’ai changé d’avis au dernier moment. Mal m’en a pris… Je me suis tourné vers la présentation intitulée « Caching 101: caching on the JVM and beyond« . Les présentateurs venaient de chez Terracotta et travaillaient sur l’implémentation d’EHCache. Je m’attendais à quelque chose de très technique, mais j’aurais dû faire plus attention à la partie « 101 » de l’intitulé. Les informations étaient très basiques, mis à part les 10 dernières minutes sur la topologie et l’implémentation de leur cache off-heap passé dans le domaine open source l’année dernière. Sans parler de leur démo, visiblement terminée à l’arrache juste avant la séance.

Tools in action

Heureusement, les 3 séances de 30mn qui ont suivi, les « tools in action », se sont révélées plus instructives. Tout d’abord une présentation assez intéressante comparant plusieurs framework de BDD. On a pu assister à différentes approches. Scala Test, par exemple, fait tout dans le code. Il est du coup plus proche du développeur. La description des tests ainsi que leur implémentation se fait entièrement en Scala. Concordion, lui, sépare la description des tests en HTML de leur implémentation en Java. Le lien se fait par des tags spéciaux dans le code HTML. Cucumber, finalement, non seulement place la description dans un fichier texte séparé utilisant un pattern connu des systèmes BDD, le « Given/When/Then », mais il infère de lui-même la signature des fonctions des classes d’implémentation, ce qui le rend très proche des MOA.

La seconde « tool in action » concernait le debugging en JavaScript. Fini le temps des alertes insérées dans le code source à partir d’un éditeur séparé. De nos jours, les browsers modernes permettent d’insérer du code à la volée, de placer des breakpoints conditionnels ou sur événement, d’afficher la stack d’appel, le contenu des objets ou le contexte des closures, et même de modifier des valeurs directement dans la console. Si l’on rajoute qu’ils sont capables de rajouter de la latence aux appels réseau, d’afficher le layout de la page comme si c’était un téléphone mobile où de stocker une librairie de snippets réutilisables pendant le débuggage, on peut simplement dire qu’ils n’ont plus rien à envier aux debuggers d’Eclipse ou autre Visual Studio.

Enfin, la journée se termine sur une présentation de l’utilisation de la librairie RxJava (vous savez, la librairie fonctionnelle) adaptée aux terminaux Androide. Il faut bien constater que les données doivent venir à l’utilisateur. Ce n’est plus à l’utilisateur d’aller les chercher. Une librairie comme RxJava utilisant le pattern Observer permet de « binder » simplement les valeurs à l’affichage, tout en gérant pour nous les notifications, les threads, et les transformations des données.

En fin de compte, une journée intéressante qui mérite bien une bonne pizza !

Devoxx, jour 2

Second jour à Devoxx, et la queue à l’entrée a disparu, puisque tout le monde a son pass. Et surtout, c’est le démarrage de l' »exhibition room ». À côté des géants comme Oracle et Red Hat (mais pas de Google), on retrouve d’autres noms connus tels que JetBrain ou Zero Turnaround. On essaye de nous acheter à coups de bonbons ou de bières, on essaye de nous éblouir avec des Legos Mindstorms et des imprimantes 3D. Bref, il est grand temps de quitter ce paradis du marketing pour assister à la première université de la journée.

Shooting the rapids par Maurice Naftalin et Kirk Pepperdine

Et pour moi, ce sera Maurice Naftalin et Kirk Pepperdine. Maurice est connu pour son livre sur les Generics qui fait référence, et plus récemment pour son nouveau livre sur les performances de la Stream API. Kirk, lui, est une référence en matière de performance puisqu’il est l’auteur de la « Java Performance Newsletter ». Dans des séquences de live coding, on a pu découvrir comment Kirk Pepperdine s’y prend pour mettre à nu des problèmes de performance courants dans un code utilisant des streams, tout en nous montrant l’outil Censum, développé par sa propre compagnie JClarity. On a pu aussi apprendre quels sont les challenges du framework Fork-Join qui est derrière les streams parallèles. Pendant la séance de questions-réponses qui a suivi, Mark Stuart de chez Oracle à répondu à la question suivante: « Pourquoi ce ne serait pas la JVM qui déciderait quand utiliser plutôt une parallèle stream ». La réponse était que la technologie des parallel streams en est encore à son balbutiement, et l’on est encore incapable de savoir dans quelles conditions une solution parallèle serait plus performante.

Modular Development with Java 9

Si vous aimez les questions-réponses, il ne fallait surtout pas manquer la session qui a suivi la pause déjeuner : « Modular Development with Java 9« . Nous avons eu droit à Mark Reinhold et Alan Bateman, deux des grands architectes de la plateforme Java, qui nous ont expliqués les bases de la grande nouveauté promise pour la sortie de Java 9 prévue pour septembre 2016: les Modules. Aussi connus sous le nom de projet Jigsaw, les modules devraient changer la façon dont les librairies Java seront compilées, packagées, déployées et exécutées. Beaucoup de changements donc à prévoir, entre la disparition de la distinction entre JRE et JDK, le remplacement du classpath par le module path, l’interdiction d’accès aux packages internes de Java, et une flopée de nouveaux paramètres aux outils de base tels que  » java », « jar » ou « javac ». Les Modules vont nous obliger à avoir une API plus propre, avec une hiérarchie plus claire entre nos packages. Des chemins de migration sont prévus pour que chacun s’y mette à son rythme.

Cette session a suscité beaucoup de réactions, puisque 60% du temps s’est passé à répondre aux nombreuses questions de l’audience. Une question qui m’a beaucoup plu (en particulier parce que c’est moi qui l’ai posée, et pour ceux qui me connaissent et se demandent comment j’ai fait pour poser une question devant une salle de 600 personnes, je l’ai tweetée) était liée aux tests unitaires. En effet, le système de Modules interdit d’avoir le même package déclaré dans deux Modules différents. Or, il est de pratique courante de séparer le code des tests unitaires dans un autre répertoire, avec sa propre dépendance vers Junit ou Mockito par exemple, mais d’utiliser le même package que la classe testée. Alan Bateman nous a dévoilé l’existence d’un système d’injection de classes de test et de ses dépendances, avec une syntaxe assez affreuse, je dois bien le dire. Mais l’idée est que cette syntaxe sera cachée par nos outils de build.

Tools in action – No SQL

Retour des « Tools in action ». J’ai décidé de me faire une petite cure de NoSql. Tout d’abord avec Firebase, une base de données orientée documents qui permet de créer des applications web sans serveur. En effet, cette base gère les notifications d’évènements, les droits utilisateurs, ainsi que les connexions et déconnexions. Mathilde Lemée nous a démontré dans une séance de live coding qu’implémenter un programme de morpion agrémenté d’un chat rudimentaire ne prenait que quelques minutes.

À la suite de quoi, j’ai assisté à la présentation sur OrientDB, qui nous est vendu comme la seconde génération de bases de données NoSql. J’ai toujours pensé qu’il faut choisir le bon outil pour la bonne donnée. Ai-je besoin d’une base relationnelle? Orienté document ? Clé-valeur ? Ou plutôt graphe? OrientDB nous répond : pourquoi choisir ? Pourquoi ne pas tout avoir? Des données stockées dans des documents, avec ou sans schéma, reliés dans un graphe, avec un langage SQL sur stéroïdes. Rajoutez le sharding et la réplication, un module d’administration web, un driver JDBC. Rajoutez encore une notion de classe de documents avec héritage, des transactions, et une API Java. Comment résister?

La dernière présentation de la journée traitait de Finagle, une technologie RPC haute performance créée par Twitter et basée sur Netty, passée dans le domaine de l’open source en 2011. La technologie Scala utilisée était peut-être trop me demander pour une fin de journée, et je n’ai pas prêté l’attention que cette présentation méritait. Il est vraiment temps que je rentre à l’hôtel.

Journal d’un devoxxien en Belgique – Jours 3 et 4