JavaFX – jamais parti, déjà has been ?

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 skinning CSS 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 ?..

Tweet about this on TwitterShare on FacebookGoogle+Share on LinkedIn

12 réflexions au sujet de « JavaFX – jamais parti, déjà has been ? »

  1. Je vous trouve très dur… Autant JavaFX 1 avait beaucoup de lacunes, autant la version 2 apporte beaucoup de fraicheur.

    De plus JavaFX permet de répondre à un marché où Flex et Silverlight ne sont plus présents. A savoir une véritable utilisation déconnecté et multiplate-forme. Lorsque les données sont sensibles et ne doivent pas être hébergées sur internet, la seule possibilité reste un client dit lourd.

    1. “un marché où Flex et Silverlight ne sont plus présents”

      => je ne sais qui est le plus dur, entre nous 😉

      Sur “le marché”, en termes de compétences, c’est le jour et la nuit !

      1. Quelles solutions existent aujourd’hui pour faire une application complètement offline ? Je ne parle pas du storage HTML5 fortement lié au cache du navigateur !

        1. Une application complètement offline… on n’est plus dans le RIA, là, n’est-ce pas ? Quoi qu’il en soit, mon point est de dire que cette technologie n’a RIEN de révolutionnaire, y compris et surtout en termes de productivité. D’où à mon avis son manque d’attractivité, et donc son retard d’adoption qui est le critère prépondérant dans un contexte professionnel.
          JavaFX, ça marche sans doute très bien, je ne dis pas le contraire. Seulement cela reste une surcouche à des choses déjà disponibles (Swing, WebStart). Et une surcouche relativement légère en termes de composants avancés. Faire du XML et des graphiques c’est bien, mais proposer des saisies complexes ça serait mieux. Même contraint au off-line, l’utilisateur ne comprendra pas d’avoir une moins bonne ergonomie en “lourd” qu’avec son navigateur. Et il faudra donc déployer plus d’efforts pour atteindre le même résultat.

          1. Visiblement, vous n’avez pas utilisé FX. Cette techno dépasse complètement swing. Bref. J’ai lu à cause du titre, j’aurais pas du.

          2. Entièrement d’accord, que ce soit en terme de possibilité(Interface riche) que de simplicité d’utilisation (l’architecture est épuré et profite du REX de Swing en apportant plus de simplicité), la techno JavaFX dans sa version 2 est une avancé technologique de poid face au très vieillissant Swing. Notons que l’adoption limitée est dû à plusieurs facteurs, autre que purement technologiques, notamment le nouveau langage de scripting de JavaFX 1.0 rebutait, d’ailleurs il ne fait plus partie de JavaFX.

            N’oublions pas, qu’aujourd’hui l’interface Windows 8 est riche, ios 7 est riche, etc. a très court terme les applications swing feront réellement hasbeen…

          3. Bonjour,
            Non, visiblement vous ne l’avez pas lu (ou compris). J’appuis tout à fait l’idée que Java FX soit une meilleure techno que Swing.
            C’est juste que pas grand monde, apparemment, ne s’en sert…

  2. Je confirme que JavaFX à de l’avenir, comparée aux centaines de frameworks “tendances” html5/css qui oblige à récoder entierement l’UI tous les deux ans…

    1. Bonjour… “red”,
      Cette article a vocation à se prêter à la polémique, bien sûr. Auriez-vous des éléments factuels et constructifs à nous soumettre, par hasard ?

  3. Mr ESCOLAN, Je veux avoir votre avis suite à la sortie de JAVA 8 ( la RoadMAP JAVA9p et les avancés concrétisées dans le cadre de projets communautaires autour de JAVA FX.

    D’après ce que j’ai lu, JAVAFX a un belle avenir …

  4. je pense qu’actuellement la donne a changé pour JavaFX depuis la publication de ce ticket, d’ailleurs oracle ont misé le tout dessus (Web et desktop) les langage de script est abandonné qui est une très bonne chose,

    mais perso, j’aime toujour swt/JFace

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


*