Ce second article résume mes trois dernières journées de Devoxx Belgium 2017. Le mercredi, le jeudi et le vendredi matin sont complètement différents des deux premières journées. Le nombre de participants est très important et les sessions sont des conférences de 50 minutes.

Le rythme est rapide ponctué par 8 sessions en parallèle : il faut donc faire de choix mais finalement ce n’est pas très grave car toutes les sessions sont filmées et peuvent être visualisées sur YouTube.

Les keynotes de Devoxx Belgium

Mercredi commence par des keynotes :

• Welcome par Stephan Jansen : Stephan nous accueille pour cette 16^eme édition et nous donnes quelques informations. Cette édition bat plusieurs records : elle est totalement remplie au mois d’août, 878 propositions de sujets revues par les détenteurs de golden tickets, 220 speakers.
• Move Java Forward Faster par Mark Reinhold et Brian Goetz : Java 9 ne casse pas tous mais casse certains choses : de nombreux frameworks et outils sont compatibles avec Java 9. Pour tenir compte des remarques de la communauté, la prochaine version de Java au mois de mars prochain sera 10.
  Mark revient sur certaines informations erronées sur le nouveau modèle de livraison de Java notamment les versions non LTS ne sont pas expérimentales et il faut suivre les releases pour faciliter la migration vers la version LTS en production. Les versions 11 et 17 seront des LTS. Brian Goetz termine par un aperçu rapide du projet Amber
• CERN from an IT perspective par Derek Mathieson : la session ayant eu la meilleure note parmi toutes celles proposées durant la semaine
• Move Slow and Mend Things par Kevlin Henney

 

Kotlin for Java Programmers

Venkat Subramaniam nous présente une petite partie des fonctionnalités qui lui font aimer Kotlin. De nombreuses fonctionnalités sont déjà présentes dans différents langages dont Kotlin a fait une synthèse pour obtenir un langage moderne.

 

Modular Development with JDK 9

Alex Buckley nous fait une introduction du système de modules de Java 9. Les modules impactent toutes les couches d’une application : le langage Java, la JVM,  les outils, le JDK lui-même, les dépendances et l’application elle-même.

Une application est composée de classes, organisées en packages. Un module est un ensemble de packages réutilisable. En Java 9, une application est composée de modules. Les modules introduisent trois niveaux de visibilité qui remplace la visibilité public de Java avant sa version 9.

Les modules offrent une encapsulation forte et une gestion fiable des dépendances. Ils ont définis grâce à un descripteur de module module-info.java.

Lors de l’exécution d’une application modulaire, il y a plusieurs contraintes :

• Tous les modules requis doivent être accessibles
• Les modules ne doivent pas avoir de dépendances cycliques
• Deux modules ne doivent pas avoir le même package (split packages). Cette règle peut avoir des conséquences lors de la modularisation d’une application

La migration vers les modules peut utiliser plusieurs approches

• Top down, facilité en utilisant jdeps
• Utilisation des automatic modules

Les modules du JDK relatifs à Java EE (JAX-B, JAX-WS, …) doivent être ajoutés au module path en utilisant l’option –add-modules.

L’utilisation de la réflexion sur des classes du JDK peut être autorisée en utilisant l’option –add-opens

 

Modules in One Lesson

Une session de live coding durant laquelle Mark Reinhold Utilisation de JShell pour obtenir le module d’une classe Des informations sur la façon dont le JDK a été modularisé Les informations sur les modules contenues dans la JavaDoc Exécution de l’applications SwingSet2 fournie avec Java 1.2 Modularisation d’une petite application composée de deux modules Illustration de différentes erreurs pouvant survenir lors de la mise en œuvre des modules Utilisation de jlink pour créer un environnement optimisé d’exécution de l’application modulaire

 

JUnit 5 — The New Testing Framework for Java and Platform for the JVM

Marc Philipp et Sam Brannen nous présente la cinquième version du framework de tests le plus utilisé.

Une nouvelle version de JUnit est requise car Junit 4 à 10 ans, JUnit n’est pas utilisé que pour les tests unitaires mais aussi les tests d’intégrations, JUnit doit être rendu modulaire et plus facilement extensible et enfin profiter des fonctionnalités de Java 8.

Mais JUnit 5 c’est aussi et surtout un chargement d’architecture pour rendre le framework plus modulaire. JUnit 5 est compose de 3 parties :

• Platform : le nécessaire pour découvrir et exécuter des tests
• Jupiter : un nouveau modèle de programmation et d’extension reposant sur des annotations et un API.
• Vintage : pour l’exécution de tests JUnit 3 et 4

JUnit Jupiter propose de nombreuses fonctionnalités :

• Assertions et assomptions dans un nouveau package,
• Personnalisation du nom des tests, tags,
• Exécution conditionnelle de tests,
• Injection de dépendances dans les constructeurs et les méthodes de test,
• Support de Java 8 : expressions Lambdas, annotations répétées, default méthodes,
• Support des classes imbriquées,
• Tests répétés,
• Tests paramétrés,
• Tests dynamiques, …

 

Lazy Java

L’évaluation lazy permet de retarder l’évaluation d’une expression au moment où elle est requise. Mario Fusco nous explique les intérêts de l’utilisation et la facilité de mise en oeuvre grâce aux expressions Lambda de Java 8. L’évaluation lazy peut également être utilisé dans la mise en œuvre de certains patterns.

 

Migrating to Modules

Une session de live coding durant laquelle Mark Reinhold migre une application pour la rendre modulaire et une bibliothèque dont elle dépend (jackson 2.6.6). Les différentes étapes effectuées par Mark permettent de comprendre les différentes problématiques et solutions pour y répondre :

• Création d’un descripteur de modules (exports et requires)
• Utilisation des automatic modules
• Construction d’un jar modulaire
• Permettre l’utilisation de l’introspection sur des classes du module (clause opens dans le descripteur de modules)
• Utilisation de jlink pour créer un environnement d’exécution dédié
• Modularisation pour l’exemple de la bibliothèque Jackson (ne faire cette action que si l’on est le responsable de la maintenance de la bibliothèque)
• Utilisation de jdeps pour déterminer les dépendances et créer un descripteur de module

 

 

Polishing the Diamond: Core Library Improvements in Java 9

Richard Warburton et Raoul-Gabriel Urma nous présente des fonctionnalités de Java 9 dans une session de live coding utilisant JShell de Java 9 : Les fabriques of() des collections de type List, Set et Map et ofEntries() de Map Les opérations ofNullable(), takeWhile(), dropWhile(), et une surcharge de iterate() de l’API Stream Les méthode filtering() et flatMapping de l’interface Collector Les méthodes stream(), ifPresentOrElse() et or() de la classe Optional

 

Shenandoah: The Garbage Collector That Could

Cette session très pointue requiert une bonne connaissance dans les ramasse-miettes. Après une introduction sur les ramasses miettes existants (Serial, Parallel, CMS, G1 , Aleksey Shipilev nous détaille le ramasse-miettes Shenandoah. Son but est de limité les temps de pause sur des heap de très grande taille. C’est un ramasse-miettes régional qui réalise une très large partie de ses 3 activités en parallèle :

• Concurrent mark
• Concurrent evacuation
• Concurrent update references

Aleksey détaille les problématiques liées à l’exécution en parallèle de ces activités.

 

Java 9 VarHandles – Best practices, and why?

Tobi Ajila, qui est développeur sur OpenJ9, nous présente l’API VarHandle introduite dans Java 9 via la JEP 193. Le sujet n’est pas simple car il concerne le JMM (Java Memory Model) et plus spécifiquement la gestion des accès concurrents à une donnée mais sa présentation est plutôt claire et bien illustrée par rapport à un sujet complexe. Après une introduction sur le JMM, il détaille les différentes fonctionnalités de l’API :

• Les types de VarHandles,
• Memory ordering modes,
• Les méthodes d’accès,
• Le lookup et l’invocation,
• Les différentes fences
• Une comparaison Unsafe / VarHandles
• Un point sur les performances

 

Collections Refueled

La session Stuart Marks concerne les évolutions dans l’API Collections en Java 9 : l’ajout de fabrique pour créer facilement des instances de type List, Set et Map qui ne soient pas modifiables. Toute une session sur une seule fonctionnalité de Java 9 peut paraitre très long mais Stuart nous donne beaucoup d’informations sur les choix d’implémentations utilisés et les conséquences qu’ils impliquent. Il termine en nous donnant quelques évolutions possibles dans les collections pour Java 10.

 

Java Language Futures — All Aboard Project Amber par

Dernière session de ce Devoxx avec Brian Goetz qui nous présente les différents sujets en cours d’étude relatifs au projet Amber, un des projets qui devrait être intégré dans une prochaine version de Java. Il y d’ailleurs d’autres projets en cours notamment Valhalla, Paname et Loom.

Le projet Amber dont la description est « Right-sizing language ceremony » a pour but d’améliorer le langage Java pour rendre l’écriture de certaines fonctionnalités plus simple. Il contient plusieurs fonctionnalités :

• Local variable type inference : l’idée est d’étendre encore l’inférence de type introduite en Java 5 et enrichie en Java 7 et 8 pour l’utiliser dans la déclaration de variables locales. Comme le nom d’une variable est généralement plus importante que son type, le compilateur pourrait inférer le type qui serait remplacer par un mot clé (peut être « var »)
• Data classes : beaucoup de classes servent uniquement à encapsuler des données. Leur écriture requiert de nombreuses lignes de codes avec peu de valeur ajoutée et à fort risque d’erreurs. Le but est de réduire la quantité de code à produire pour de telles classes.
• Improved switch : pour permettre à un switch de faire un test-type pattern
• Pattern matching : probablement la fonctionnalité la plus puissante mais aussi la plus complexe à appréhender
• Safer serialization

Ces fonctionnalités sont en incubation et notamment la définition des mots clés qui seront utilisés ne sont pas encore figée.

 

Les autres sessions

Evidemment, vu ma forte culture Java, une majorité des sessions auxquelles j’ai assistées concerne Java mais Devoxx c’est aussi de nombreuses autres sessions sur de nombreux sujets autour de différents thèmes :

• Java Language
• Server Side Java
• Cloud, Containers & Infrastructure
• Programming languages
• Methodology & Culture
• Big Data & Machine Learning
• Mobile & IoT
• Methodology & Culture
• Mind the Geek
• Modern Web
• Architecture & Security

Devoxx c’est donc aussi beaucoup de sessions autour des sujets du moment dans le secteur de l’IT.

Pour ceux qui ne sont pas « fluent in english », n’hésitez pas à assister à la 7^eme édition de Devoxx France qui aura lieu du 18 au 20 avril 2018 pour améliorer vos connaissances grâce à des sessions variées, rencontrer d’autres développeurs et venir nous voir sur le stand Oxiane.