Devoxx, c’est un peu le pélerinage obligatoire des développeurs Java, au moins européens. Anvers, c’est un peu comme la forêt des Carnutes. Tous les ans à pareille époque, les druides du développement Java, Web, Android, s’y rassemblent, attirés par un étrange appel.

Cette année encore les tribus sont venues de nombreux pays, une quarantaine, et de loin, au-delà des mers. Cette année encore les grands prêtres étaient là, et nous ont apporté la bonne parole. Car d’ici l’an prochain, nous auront eu une nouvelle version de Java, la 8, la tant attendue 8 devrais-je dire. Présenter cette nouvelle version est donc un enjeu, stratégique et commercial pour Oracle.

Donc Java 8 arrive, plus que 4 mois au moment de la publication de ce blog, même si la version disponible aujourd’hui permet de commencer à apprendre les nouvelles API, notamment Stream et Collectors. Car oui, avec l’arrivée de Java 8, il va falloir affuter ses connaissances. Des nouvelles choses, il y en a : le langage change, les API changent, les patterns changent. Et même si cela nous touche moins en tant que développeur, la JVM elle-même change.

Avec la présence de Mark Reinhold, Brian Goetz et Paul Sandoz, Devoxx 2013 était sans aucun doute la meilleure occasion de faire l’état des lieux sur tout ceci. Brian nous a décrit le pourquoi des choses, en nous retraçant le cheminement des réflexions. Paul nous a expliqué comme l’API Stream fonctionne en interne. Une parole d’expert, vu que l’API Stream, c’est lui qui l’a écrite ! Et enfin, Mark nous a donné des pistes sur les axes de travail suivis dans le développement de Jigsaw, ou de ce qu’il en reste, ou plus exactement de ce que cela va devenir.

A peek under the hood

La conférence de Brian Goetz a pour objet de détailler la façon dont les lambdas sont implémentés en Java. Java est un des derniers langages populaires à introduire les lambdas dans ses fonctionnalités (C++, et C# l’ont depuis longtemps). Donc les implémentations, leurs qualités, et leur défauts sont connus, ce qui est bien sûr un avantage. Sur le thème « la première idée que l’on peut avoir n’est pas toujours la meilleure », Brian égrène les premières idées, évaluées, implémentées, évaluées à nouveau, et finalement… non retenues. Belle leçon d’humilité de la part d’un tel expert ! L’implémentation des lambdas en Java va concerner 9 millions de développeurs, et encore plus d’applications. L’erreur n’est donc pas autorisée : elle doit être parfaite, la plus performante possible, et ne doit pas fermer la porte aux implémentations futures de la JVM. C’est le cas.

Cette conférence est un must, Brian nous livre un discours très technique, complexe, mais décrit aussi sa démarche intellectuelle, empreinte d’une grande humilité.

Java 8 : lambdas in the stream

Les lambdas ne sont pas une fin en soi. Brian Goetz nous le dit : l’objet premier des possibilités d’un langage est de permettre le développement de nouvelles API, et l’apparition de nouveaux patterns. Cet objectif a été pleinement atteint avec l’arrivée des lambdas, puisqu’une nouvelle API, Stream, arrive, permettant de les exploiter pleinement dans le contexte applicatif du traitement de grandes collections de données en mémoire. Le contexte applicatif est précis et a du sens. Il y a 20 ans les données des applications étaient massivement enregistrées dans des bases de données relationnelles. L’approche canonique consistait alors à effectuer les traitements sur les données au sein de la base, et de sortir les résultats pour exploitation dans le code applicatif. Transférer les données dans l’application pour les y traiter était une hérésie !

Les choses ont changé, les applications ont beaucoup plus de mémoire à leur disposition, et les JVM fonctionnent mieux dans les grands espaces mémoire, grâce entres autres aux nouveaux GC. Par ailleurs, on sait que l’approche relationnelle ne permet pas de traiter les requêtes au-delà d’un certain rythme, assez rapidement atteint par les applications web populaires. La solution à ce problème porte un nom : NoSQL. Il peut devenir alors intéressant de transférer les données en mémoire afin de les y traiter, de façon plus puissante et éventuellement plus performante, que d’utiliser les moteurs de traitement parfois très frustes intégrés aux bases NoSQL. Le NoSQL offre finalement ici une fonctionnalité assez innatendue.

Traiter ces grands volumes de données, c’est précisément ce pourquoi l’API Stream a été conçue, objet de la présentation de Paul Sandoz. Cette API peut paraître simple au premier abord, et elle est. Cela dit, l’utiliser de manière efficace est en fait complexe, car l’interaction entre les détails d’implémentation et le parallélisme notamment est très délicate à maîtriser. Nouveaux concepts, nouveaux patterns, donc nouveaux bugs, et surtout nouvelles opportunités !

Et Jigsaw dans tout ça ?

Il fallait bien donner aux geeks une occasion de troller, et c’est Mark Reinhold qui s’y est collé. Jigsaw, le tant attendu Maven à la sauce Java, l’inconcevable entrée de OSGI sur notre plateforme, ne viendra pas. Du moins pas sous la forme dans laquelle on l’attendait. Je pense que la raison en est simple. Maven, même s’il est décrié par tant d’utilisateurs, même si cet outil est vieillissant et ne montre pas une activité débordante sur le front des nouveautés (la liste des dernières mises à jour est d’une tristesse…). Maven reste un standard de fait, qui a façonné les processus de construction et de livraison de nos projets.

D’un autre côté OSGI, qui ne fait pas vraiment l’unanimité lui non plus, gère les classpath complexes, les JARs aux contenus cachés, et les conflits de version. J’aurais bien ajouté qu’il gérait remarquablement bien le chargement et déchargement de dépendances à chaud, mais le fait qu’Eclipse me conseille un redémarrage à chaque changement de plugin me rend méfiant sur ce point. Est-ce vraiment bien fiable ?

Donc non,  Java n’ajoutera pas un outil de plus en doublon de Maven d’un côté ou d’OSGI de l’autre. Java va se doter d’un linker, qui permettra de créer des runtimes légers à la demande, et qui va s’accompagner, dès Java 8, de profils censés répondre aux problèmes de déploiements sur matériel léger et peu pourvu en mémoire. Pas très excitant, reconnaissons-le, mais après tout, si c’est efficace…

Devoxx, la conférence incontournable

Oui, Devoxx est sans aucun doute incontournable.

Oracle choisit Devoxx pour servir son discours aux développeurs européens. Les plus grands speakers et spécialistes sont venus, avec pour objectif de présenter, d’expliquer, de convaincre. De montrer les axes stratégiques aussi : l’Internet of things, Java sur les petits appareils connectés. Leur vidéo d’introduction est passionnante à analyser. Qu’y aurait-on vu il y a 6 ans ? Probablement des salles serveurs, des datacenters, des masses de données traitées en temps réel pour le business, la vente en ligne, l’informatique de loisir. Qu’y voit-on aujourd’hui ? Des évocations de tous ces petits appareils que nous portons : smartphones, lunettes, montres, bracelets de surveillance bio-médicale. Pour Oracle, qui n’est pas une entreprise de philantropie, l’enjeu commercial réside dans cette multitude d’appareils connectés, communiquants, tous pourvus d’une JVM.

Google n’est pas en reste non plus. Que viennent-ils faire à Devoxx ? Annoncer en grande pompe la sortie de Dart 1.0 devant un parterres de 3500 développeurs comblés. Peu importe si la présentation manque un peu de punch, et est faite à l’ancienne (next slide please). Cela fait partie de la com’ ! Google met en avant ses développeurs de génie, et si ne sont pas les meilleurs communiquants peu importe. Le public veut voir des développeurs, de la technique. Servir du bullshit marketing à Devoxx, c’est le gadin assuré !

Que des sociétés majeures comme Oracle ou Google choisissent Devoxx pour leurs annonces est un excellent signe pour nous. Signe que Devoxx est une conférence prise au sérieux, une marque qui a su construire sa réputation au fil des ans. Un lieu particulier aussi, dans lequel les grandes marques qui s’affrontent ailleurs cohabitent en paix. Aurons-nous un Java One Europe, ou un Google plus de ce côté-ci de l’Atlantique ? Pas besoin, nous avons Devoxx !

Revenir de Devoxx

Je vais à Devoxx parce que, malgré ses 3500 participants, malgré ses salles immenses (près de 800 places pour la plus grande), malgré l’incroyable stress que doit représenter une telle organisation, l’ambiance y reste cool. Stephan et l’ensemble de l’équipe d’organisation s’y promènent avec le sourire. On y prend le temps de se serrer les mains, de discuter, d’échanger des blagues, de se congratuler. Devoxx, malgré le gigantisme, c’est l’ambiance d’un JUG de 50 personnes. Vous n’y croyez pas ? Vous avez raison, allez donc vérifier vous-même !

Je vais à Devoxx aussi pour y pêcher des idées, au travers des conférences auxquelles j’assiste, et des innombrables discussions (techniques ou pas) que l’on peut y avoir. Pour échanger deux heures avec Brian Goetz sur la bonne façon de présenter les lambdas et l’API Stream. Pour s’asseoir avec Paul Sandoz autour d’un écran et parler parallélisation des algorithmes. Pour y trouver de l’inspiration, et pour savoir quel sera mon programme de travail pour l’année qui vient.

Et puis j’y vais aussi pour y parler, je ne vais pas le cacher. Cette édition a tenu pour moi ses promesses et bien au-delà, sur tous ces points. De mon université, précieux et unique lecteur, je ne t’ai pas parlé dans ces lignes, mais ce n’est que partie remise.

De belles inspirations en perspective !