Interview de Thierry Wasylczenko, développeur Java et JavaFX

Je suis Thierry, développeur full stack, essentiellement Java/JavaFX, depuis une dizaine d'années. J'ai une forte appétence pour transmettre mes connaissances, que ce soit lorsque j'enseignais les technologies Java à SUPINFO ou par le biais de formations internes, de conférences et de JUGs. Voyant le cycle de vie d'un logiciel de bout en bout, j'ai également un très fort attrait pour les outils de build et de manière générale, pour tous les outils facilitant la vie d'un développeur.

Diplômé d'un IUT en informatique j'ai rejoint SUPINFO en 2007. À partir de 2008, j'y ai enseigné les technologies Java (ME, SE et EE) et j'ai été le professeur référent de ces technologies. Cela consistait à gérer les intervenants, rédiger les supports de formation et les évaluations des étudiants. Depuis 2018 je possède également une certification DevOps.

Professionnellement, j'évolue au sein d'entreprises éditrices de logiciels dans plusieurs domaines : d'abord la santé, puis la gestion documentaire et dernièrement le milieu bancaire.

Au quotidien, je suis amené à porter diverses casquettes du fait de l'équipe à laquelle j'appartiens mais aussi de par mon côté « touche à tout ».

L'une d'entre elles est celle du coach technique. J'assiste des collègues ou des équipes pour mettre en place les bonnes pratiques de développement, de nouveaux outils, ainsi que de nouvelles méthodologies. Le périmètre est vaste : il peut aller de la simple formation à un langage, à la mise en œuvre d'outils de CI/CD ou de build. J'essaie d'intervenir au maximum sur tout le cycle de vie d'une application. Afin de pleinement remplir ce rôle de coach, je peux être amené à réaliser des formations, des BBL, des clubs de lecture technique, des séances de visionnage de conférences techniques. J'adapte le format en fonction du besoin.

Une autre casquette est bien évidemment celle de développeur. En fonction de l'objectif à atteindre, je peux être amené à choisir mon langage de développement : Java ou kotlin pour la JVM, go pour des utilitaires, ou encore NodeJS. Je ne suis absolument pas restreint dans mes choix, pourvu qu'ils soient pertinents. Cela me permet de me tenir à jour technologiquement.

Et la dernière casquette peut être celle d'un Ops. Je peux aider à la mise en œuvre d'infrastructures à l'aide de technologies comme Docker, Kubernetes ou Terraform. Dans certaines entreprises, j'ai épaulé les Ops pour réaliser les installations de nos produits et leur fournir du support en cas d'incidents client.

Depuis quelques années je développe SlideshowFX à titre personnel, un outil en JavaFX qui permet de réaliser des présentations HTML5. En tant que développeur et coach, les présentations que je suis amené à réaliser sont moins évidentes à préparer sur des éditeurs comme PowerPoint ou Keynote. SlideshowFX me permet d'y intégrer du code, du code exécutable directement depuis la présentation, de proposer un chat aux participants pour y poser des questions, des quizs, etc. Ce projet me sert de laboratoire technologique au sein duquel je teste ce dont j'ai envie : des librairies (comme vertx), des mécanismes (authentification OAuth avec Dropbox, Drive ou Box), des outils (de build, de qualité de code, LeapMotion), des services (comme Travis et AppVeyor), des bonnes pratiques et méthodologies. C'est le projet qui me permet de rester au goût du jour techniquement.

Dans une très moindre mesure, je développe également jstackfx qui permet d'analyser des Thread dump de manière plus aisée que de parcourir les fichiers. C'est également un outil en JavaFX.

Des idées, j'en ai beaucoup. Du temps un peu moins ! J'ai envie de faire évoluer SlideshowFX à la fois au niveau fonctionnel (tout en restant pertinent sur l'utilité des fonctionnalités servant durant une présentation ou dans sa confection), au niveau de sa prise en main en fournissant une bibliothèque de template, mais aussi au niveau technique. Actuellement, le projet est en Java/FX 8. Je souhaite passer le cap des nouvelles versions de Java. Malheureusement, certaines librairies que j'utilise ne sont pas compatibles Java 9 et je me retrouve bloqué le temps de trouver une solution de contournement. Mais il y a également les outils fournis au sein du JDK qui ne me permettent pas de packager l'application. Ces problématiques sont en train d'évoluer depuis Java 12 et peut-être 13.

Pour nos lecteurs ne connaissant par ZeroTurnaround, il s'agit de la société qui propose, entre autres, l'outil JRebel permettant de modifier à chaud le code des applications Java.

Tout à commencé lorsque je souhaitais trouver de nouveaux défis professionnels il y a quelques années. ZeroTurnaround publiait une offre d'emploi pour un rôle de Technical Writer. Appréciant beaucoup l’écriture des articles techniques, j'ai postulé et, j’ai constaté lors de l'entretien, que l'ensemble de l'offre ne me correspondait pas. Néanmoins, on m'a proposé d'écrire gratuitement des articles, quand j'avais de la disponibilité, sur des sujets qui me tenaient à cœur et de les publier sur le blog de RebelLabs. Mon appétence pour le partage des connaissances m'a fait accepter. Cela permet également d'avoir des retours divers et variés concernant les sujets des articles et de ne pas être prisonnier de ses idées et avis.

JavaFX 1 était un échec cuisant : son langage de scripting similaire à Flash/Flex/Silverlight a perdu tous les développeurs Java. Il n'était même pas possible d'utiliser des librairies Java classiques. La version 2 a été une révolution pour le framework : il s'est réintégré au monde Java et a clairement été annoncé par Oracle comme le successeur de Swing. Les nouvelles versions apportent surtout de nouveaux composants, mais, ne nous le cachons pas, pas de révolution.

D'autres entreprises, comme JPro, permettent d'intégrer des applications JavaFX directement dans un navigateur et cela sans plugin. Je ne suis pas convaincu par la pertinence de tels outils : les technologies web sont suffisamment avancées pour proposer du contenu riche et certaines, telles que Flash ou Silverlight, en ont fait les frais.

De manière très naturelle : j'adore créer des IHM client lourd et j'ai assisté à une présentation JavaFX 2 à Devoxx France qui m'a convaincu. Après la présentation, j'ai passé mon temps sur le stand Oracle à discuter ! En testant le framework, je l'ai découvert, apprivoisé et beaucoup apprécié. Et l'histoire continue toujours.

Dans son évolution, je n'ai pas d'implication actuellement. Maintenant que le framework est Open Source, j'aimerais proposer de nouveaux composants notamment, même si des librairies telles que TilesFX, ControlsFX et bien d'autres existent. Mais le temps me manque :)

En logiciel Open Source, SlideshowFX et jstackfx dont je vous parlais précédemment.

En interne au sein des entreprises dans lesquelles j'ai évolué :

• un outil permettant de générer les numéros de licence d'un produit. C'était le début des interfaces avec le style Metro et j'ai réalisé une interfaces à tuiles. Elle sert surtout aux Ops lors des installations produit ;
• un outil permettant de requêter une base de métriques H2 ;
• un outil de type client REST qui permet d'appeler directement les API REST du backend d'un produit. Les endpoints et leur configuration sont stockés dans un fichier de configuration, ce qui permet aux développeurs de faire évoluer les API supportées sans avoir à modifier le code métier de l'application. Pour cette application, j'ai utilisé JavaFX et Kotlin pour changer un peu.

D'un point de vue évangélisation, j'ai réalisé quelques sessions au sein de JUGs (ElsassJUG, marsJUG, Nantes JUG, Finist JUG, NormandyJUG) et conférences (Devoxx France et UK, SoftShake).

Pour nos lecteurs, la société Gluon est très présente pour proposer de nombreuses évolutions pour JavaFX. Elle fournit également des binaires JavaFX sur différentes plates-formes x86, ARM.

Gluon est devenu l'acteur principal pour JavaFX depuis qu'Oracle a montré son désintéressement. À mon sens, c'est un mouvement naturel qui s'est opéré. En effet, Gluon a montré son souhait de supporter JavaFX sur les plates-formes mobiles et a développé des produits tels que Gluon CloudLink afin de faciliter et d'optimiser la communication d'une application JavaFX (sur mobile notamment) avec un backend Cloud.

Mais Gluon a également récupéré le projet Scene Builder délaissé par Oracle. C'est un outil permettant de créer les IHM JavaFX de manière très aisée en drag'n'drop. N'étant absolument pas fan des outils de génération de code pour les IHM, je dois avouer que dès ses débuts, cet outil a généré du code de qualité et qu’il est un véritable accélérateur pour créer rapidement une IHM.

Enfin, depuis que JavaFX n'est plus inclus dans le JDK Oracle, Gluon a tout de suite récupéré le projet OpenJFX et continue son développement de manière active. Chaque nouvelle version est disponible de manière très rapprochée par rapport au JDK.

Tout récemment, Gluon a annoncé le projet Gluon Client Plugin qui permet, à l'aide de GraalVM de l'OpenJDK et l'OpenJFX, de créer des applications clientes natives.

Je vois donc ce rapport d'un très bon œil, sinon l'existence de JavaFX aurait très fortement été remise en question ainsi que les applications client lourd Java de manière plus globale.

Oui et non. Je ne choisis pas un framework en fonction d'une mode, mais plus en fonction du besoin et du contexte. Il faut la bonne technologie pour le bon projet et la bonne équipe. Les frameworks pour faire du client lourd ne sont pas nombreux, mais ils existent :

• Electron ;
• WPF pour des IHM à base de .NET ;
• WinForm ;
• Universal Windows Plateform (UWP) pour des applications Windows, tablettes etc ;
• Swing historiquement en Java ;
• JavaFX.

Chacun a ses avantages et inconvénients. L'avantage d'Electron par exemple, est de pouvoir développer en pur HTML/CSS son application et de fait, il est facilement imaginable d'avoir une version web et desktop de son application (c'est par exemple le cas de draw.io). Si l'équipe en charge des développements est majoritairement composée de développeurs avec une forte appétence pour les technologies Web, ce sera sans aucun doute la technologie choisie.

L'avantage des frameworks Microsoft est leur forte intégration avec l'OS. Cet avantage n'est pas à négliger en fonction des postes sur lesquels sera déployée la solution : intégration SSO, librairies natives pour l'observation du système de fichiers, etc.

L'avantage de JavaFX est l'écosystème colossal autour de Java. Il s'agit d'un langage connu, reconnu et éprouvé. Le framework en lui-même est bien conçu et robuste à mon sens. Réaliser une IHM JavaFX est bien plus simple que de choisir Swing. Et au même titre que XAML par exemple, JavaFX permet de faire du véritable MVC, contrairement à Swing.

Le conseil que j'aurais à donner à nos lecteurs, serait de toujours faire un choix raisonné, réfléchi et évalué.

Il est indispensable pour les technologies, librairies et SDK, d'évoluer rapidement dans notre métier, au risque de devenir très vite désuètes. Si Java est toujours un langage de choix à l'heure actuelle, c’est selon moi parce qu'il a réussi à apporter une très bonne stabilité et sécurité dans les applications professionnelles. On pourra le trouver verbeux, parfois gourmand, mais il est présent dans les entreprises, possède un écosystème gargantuesque (tant au niveau des librairies que des outils de build) et il est devenu incontournable. Voilà pour le constat.

Mais le style de programmation a fortement évolué ces dernières années et il était temps que Java prenne ces évolutions en compte. D'autres langages sont apparus et évoluent très rapidement. Il suffit de regarder Kotlin et son ascension fulgurante. Mais je pense aussi sincèrement qu'un langage est similaire à une librairie utilisée dans un projet : elle évolue, apporte rapidement de nouvelles fonctionnalités, corrige rapidement des bugs. Elle possède un cycle de vie. Un langage doit faire de même. Attendre plus de 5 ans pour une nouvelle version, de nos jours, signifie qu'un langage ou une librairie n'est plus au goût du jour. Donc, pour moi, c'est une bonne chose qu'une nouvelle version de Java apparaisse tous les 6 mois.

La montée de l'OpenJDK est quelque peu forcée par Oracle. La différence entre l'OpenJDK et le JDK « Oracle » réside dans le support apporté par Oracle. En terme de fonctionnalités, les deux sont identiques et d'ailleurs, les deux sont fournis par Oracle. Ce qui est quelque peu novateur, c'est la danse des JDK disponibles : tout le monde souhaite proposer son JDK ! Amazon, Azul, RedHat, Pivotal, etc. C'est cet aspect qui selon moi est quelque peu néfaste : quel JDK choisir ? Quel « Java » supporter ? En quel « Java » je développe ? Là où précédemment on avait un JDK, on se retrouve avec une nébuleuse qui sème la confusion. Même si Simon Ritter tente de nous rassurer dans son article Don't fear the Jave. Cela me rappelle néanmoins l'époque des JDK IBM et Apple qui différaient du JDK « standard ».

Au sujet de la modularité, je suis partagé. L'idée de charger uniquement les modules dont notre application a besoin est très alléchante et même louable. Cependant, la manière dont cette modularité a été mise en œuvre est quelque peu maladroite selon moi. Il n'est soi-disant pas obligatoire de basculer dans le monde des modules pour migrer vers Java 9+ : il est tout à fait possible d'utiliser les auto modules. Dans le cadre d'une application fonctionnant au sein d'un serveur d'application ou un conteneur de servlet, il s'agit effectivement d'un axe de migration possible. En revanche, lors du packaging d'une application JavaFX, il en va tout autrement. En effet, certains outils fournis par le JDK, comme ceux permettant de créer une application self-packagée (contenant son JRE), sont incompatibles avec les auto modules et ont même été supprimés dans le JDK 11. Il devient donc impossible de construire son application avec les auto modules, et donc la migration vers les modules est obligatoire. Pour une application JavaFX ayant peu de dépendances externes, cela ne posera guère de problème. En revanche, pour une application comme SlideshowFX, la migration est compliquée car certaines dépendances ne sont plus maintenues et/ou sont mal développées (elles ont notamment des split packages ce qui les rend incompatibles avec les modules).

Pour information, un outil, jpackage, est en cours de développement en remplacement de l'ancien outil (javapackage). Il serait peut-être disponible avec le JDK 13.

Je comprends que la mode actuelle est le cloud, le cloud hybride, les applications web, mais ce n'est pas la réalité et la globalité du marché. Des clients lourds seront toujours nécessaires. Là où d'autres technologies, comme Electron, font un pas vers le desktop, Oracle semble prendre le contre-pied. Or, dans une époque charnière du développement des applications, il faut savoir rester compétitifs sur plusieurs terrains.

Bien évidemment. J'apprécie l'agrégation des informations sur différents technologies sur les langages et les actualités informatiques de manière générale. En tant que consommateur de plusieurs sujets, technologies et méthodologies, c'est un canal des plus intéressants.

Soyons chauvins : les développeurs français ont une certaine rigueur que tous les développeurs n'ont pas. Pour avoir travaillé avec certains développeurs d'autres nationalités, je peux le dire ! Donc mes impressions ne sont que positives : le contenu est riche, à jour et pertinent ! Continuez comme-ça !

Oui ! Il est indispensable selon moi d'être en capacité de lire une documentation technique en anglais, de visualiser des présentations en anglais. Cependant, certains sujets peuvent être complexes à appréhender en anglais et pouvoir suivre un tutoriel en français (ou tout autre support) est un vrai plus ; cela ôte la barrière de la langue.