Un de nos clients est récemment venu vers nous pour être conseillé sur la technologie JavaFX. Il souhaitait avoir un retour d’expérience (un rex, comme disent les commerciaux) et un support de ses équipes qui sont expérimentées mais débutent sur cette technologie. Il faut bien avouer que nous avons été pris au dépourvu… Bien que datant de 2007 et faisant partie des standards de Java (JavaFX est intégré à la JVM depuis la version 7 ; rappelez-vous que le JDK 6 n’est plus supporté !), quasiment personne chez nous n’a acquis d’expérience dessus – Note pour plus tard : est-ce qu’on peut vraiment écrire CA dans un blog pro ?? 😉
Pour moi, il s’agissait d’une API de client lourd destinée à faire évoluer l’antédiluvienne techno Swing, pour contrer celle développée par Eclipse (RCP) SWT (c’est moi qui suppute). Or, renseignement pris, il s’avère que JavaFX se positionne dans le secteur RIA et les plateformes mobiles par l’intégration à Java ME. Donc, il faut bien admettre que cela ressemble à un projet de bon aloi, ambitieux et suivi. Quel est le problème, alors ? Je me suis mis à creuser dans les possibilités de la bête.
Comme pas mal de technos Java (souvenez-vous des EJB 2…), JavaFX a connu une première mouture partiellement avortée. A l’époque, elle nécessitait une étape de précompilation qui est aujourd’hui abandonnée pour une solution “tout Java”. JavaFX 1 disposait également d’un langage propre, JavaFX Script, abandonné également. Pendant un moment, le projet Visage a prétendu prendre la relève ; il existe également GroovyFX et ScalaFX, pour les amateurs. Actuellement, la version officielle est JavaFX 2, et une version 3 est annoncée pour cette année 2013.
Enfin, NetBeans intègre les outils nécessaires à son exploitation, et un Scene Builder est disponible pour les autres. Il y aura aussi un plugin IntelliJ IDEA, incessamment (il est encore immature, d’après ce que l’on m’a dit).
OK, voilà pour la partie historique. Alors, qu’avons-nous là ? Entre nos mains, une solution IHM événementielle multiplateforme (desktop, web) intégrant le skinningCSS pour la personnalisation du rendu et supportant HTML pour le formatage des textes. Il y a aussi des effets en veux-tu en voilà (animations, transformations, transitions animées).
Pas de dépendances volumineuses en exécution, donc, sur Java SE 7 qui devrait (n’est-ce pas) être votre JVM par défaut maintenant. Du côté des composants (UI Controls), on peut leur appliquer des layouts et tous les effets précités.
On dispose en outre d’une extensibilité poussée. D’ailleurs, JFXtras (très inspiré mais relativement étroit d’esprit) et DataFX (qui fournit un effort d’abstraction des sources de données) ne sont qu’un exemple parmi les nombreux projets avancés sur le sujet – Nan, j’déconne, en fait je n’en ai pas trouvé tant que ça 🙁
Voici un tour des composants de base de JavaFX :
Label, Button, Radio Button, Toggle Button, Checkbox, Choice Box, Text Field, Password Field, Scroll Bar, Scroll Pane, List View, Table View, Tree View, Combo Box, Separator, Slider, Progress Bar and Progress Indicator, Hyperlink, Tooltip, HTML Editor, Titled Pane and Accordion, Menu, Color Picker, Pagination Control...
De plus, JavaFX propose aussi une API de graphiques (Charts) complète, fondée sur du SVG, de quoi rendre Birt jaloux (ou pas).
Tout cela, mesdames et messieurs, pouvant coexister dans des applications Swing (par le biais d’une Scene)… Et, j’ai envie de dire : c’est bien la moindre des choses ! Parce que finalement, à mon avis, c’est ici que se trouve le “noeud d’adoption” de la technologie. Franchement, qui a envie de faire du Web avec JavaFX alors qu’il existe des frameworks web ultra poussés avec des composants surpuissants (PrimeFaces, si tu me regardes…) ?? Il n’importe donc que de savoir si JavaFX a une valeur ajoutée en terme de productivité par rapport à Swing, en se limitant aux clients lourds, donc. Sans cela, qui en voudrait ?
J’ai relevé en gras, dans l’encadré ci-dessus, tous les éléments qui me semblent nouveaux, hormis l’utilisation optionnelle du FXML (avec binding tout de même, et l’utilisation des annotations Java). Honnêtement ? C’est pas vraiment la révolution… Je ne sais pas vous, mais moi j’attends BEAUCOUP plus d’une librairie de composants ; il faut dire que j’ai fait du Flex, aussi… Pour moi, si l’API GUI de Java doit évoluer, c’est en fournissant AU MINIMUM des composants de la trempe de ce que l’on trouve sur le web. Ce n’est pas comme si les clients lourds avaient le vent en poupe, n’est-ce pas ?.. Il faudrait donc qu’ils fassent montre de capacités inédites pour percer, CQFD.
Si vous voulez ajouter facilement (et rapidement) des éléments de data visualisation à vos applications existantes, vous serez heureux d’adopter JavaFX. Je ne sais même pas si les graphiques peuvent être rendus suffisamment interactifs, d’ailleurs. Mais sinon ? Je ne vois pas comment justifier la courbe d’apprentissage d’une nouvelle technologie (in cauda venenum, il y aura forcément de la charge de débugage), simplement pour dire qu’on a arrêté de faire du Swing (de l’AWT, d’accord ; on doit poser des limites à la résistance au changement).
Ce qu’il manque à Swing “out of the box” (SwingX est mort, mais il reste JGoodies ou ASC Suite – c’est payant) , ce sont des composants avancés (un pauvre composant de saisie de dates/calendrier ; des champs auto-complétés, auto-validés ; des tables auto-paginés, auto-filtrés, auto-triés ; l’intégration de cartes géographiques ; des listes de sélection liées ; des graphes, des mindmaps ; ou que sais-je encore, clef en main). C’est quand même un comble que les interfaces utilisateur distantes soient aujourd’hui plus riches que les interfaces locales… Or, l’offre de JavaFX me semble encore inférieure à ce qui peut être fait avec HTML5. C’est la fin de la discussion, je pense… JavaFX est à la traîne, et je n’ai rien trouvé d’annoncé pour la version 3 qui remédierait à cela (Ah, il y a l’intégration de la 3D au menu – pourquoi pas ?).
[mode_perfide]A ce compte-là, on pouvait très bien se contenter des bibliothèques de composants Swing externes développées depuis de longues années. Mais c’est peut-être bêtement un problème de copyright…[/mode_perfide]
Conclusion : oui, JavaFX est décevant, non content d’avoir eu du mal à décoller. Et compte tenu des besoins en termes d’applications client lourd ces dernières années, il est tout à fait normal que son adoption soit médiocre. La tentative de vente forcée avec le JDK 7 n’y fera rien, à mon avis.
JavaFX n’a pas un problème de visibilité (des livres existent, notamment chez Apress, entre autres) mais un problème de productivité, comme on l’a vu. La pénurie de profils expérimentés risque de faire encore longtemps défaut.
C’est moche, je sais.
PS : Y aurait-t-il des volontaires pour démarrer un projet “PrimeFX” ? Levez le doigt ; personne ?..
