Discussion :

[Robin56]

JavaFX mérite-t-il son statut de remplaçant de Swing ?
Son utilisation semble peiner à se démocratiser

Comme le précise la FAQ officielle de JavaFX, cette bibliothèque remplace officiellement Swing comme bibliothèque graphique Desktop dans le monde Java. Sa première version stable (JavaFX 1.0) date du 4 décembre 2008 et avec elle marque l'arrêt des évolutions de Swing. Des corrections de bogues ponctuelles peuvent tout de même être réalisées côté Swing qui fait toujours partie des spécifications de Java SE. JavaFX 2.0 est arrivée le 10 octobre 2011 améliorant son intégration dans le monde Java et son utilisation (abandon du JavaFX Script, mise en place du FXML, etc.). Il forme la base de l'actuelle JavaFX 8. JavaFX 8 quant à elle est disponible depuis le 18 mars 2014 et fait désormais partie du JRE/JDK de Java 8.

Cependant, après presque trois ans de mise en place (et même six ans si l'on se réfère à JavaFX 2.0), JavaFX ne semble pas autant implanté que Swing lors de ses beaux jours. Rares sont les projets professionnels réalisés en JavaFX. Nous avons tenté d'expliquer les raisons poussant à ce constat :

• JavaFX comme Swing auparavant nécessite l'installation de l'applicatif sur le poste client. Dans un parc important, cette opération peut s'avérer fastidieuse surtout lors de montées en version ;
• JavaFX n'est pas intégré au sein de Java SE Embedded. Oracle laisse la communauté se charger de cette partie elle-même ;
• JavaFX comme Swing auparavant nécessite Java sur le poste client. L'introduction de javapackager permet d'empaqueter la JVM au sein de l'application et de s'abstraire ainsi des besoins d'installation de la JRE. Cependant l'applicatif embarque ainsi toute la JRE qui gonfle considérablement la taille de l'applicatif en lui-même. On peut espérer que la modularisation intégrée au sein du JDK 9 via le projet Jigsaw améliore la donne ;
• dans un écosystème où tout devient interconnecté, les applications Desktop n'ont tout simplement plus la cote. Une application Web fournit l'avantage de la portabilité (accessible partout et sur de nombreux supports mobiles) tout en simplifiant les mécanismes d'installation et de déploiement.

Toutes ces raisons permettent de fournir un début d'explication sur les débuts timides de JavaFX. À travers cette spécification, est-ce vraiment JavaFX qui est en cause ? Ou finalement, cela ne met-il pas encore plus en évidence l'hégémonie que prend le monde des applications Web sur le Desktop.

Et vous ?

Pensez-vous que JavaFX peine à s'implanter ?
Pensez-vous que le monde Desktop n'a pas d'avenir contrairement aux applications Web ?
Qu'est-ce qu'il manque à JavaFX pour réellement s'imposer ?

[Logan Mauzaize]

Le client lourd tend à disparaître ou à être remplacé par des technologies orientées Web (Electron, NW.js, Cordova, etc.). Cela permet de réutiliser des compétences voir des pans de code et l'écosystème (NPM, Lint, IDE, etc.) avec les applications Web ou mobile hybride.

Par ailleurs JavaFX semble être le fils illégétime de Swing ... Il est toujours pas intégré officiellement à Java SE. Il est bien livré avec les JVMs Oracle mais pas forcément les autres ... Ce qui signifie qu'il suffit pas d'avoir une VM Java 8 pour lancer une application JavaFX. Pourquoi alors investir dans une technologie dont on est pas sûr que les clients puissent l'utiliser ?
Sans compter que pendant les premières années de JavaFX 2.0, la documentation n'était pas des plus claires.

A cela se rajoute la méfiance à l'égard de Java suite à tous les problèmes de sécurité lié aux Applets, Java Web Start et autres.

Dernier point, je pense que les derniers à encore faire du client lourd, ce sont essentiellement des produits sous Eclipse RCP. Même s'il est possible d'intégrer du JavaFX, l'essentiel semble plutôt reposer sur SWT.

[Robin56]

Cela permet de réutiliser des compétences voir des pans de code [...]

En quoi n'est-il pas possible de réutiliser des compétences et des pans de code au sein d'une application lourde ?

Dernier point, je pense que les derniers à encore faire du client lourd, ce sont essentiellement des produits sous Eclipse RCP. Même s'il est possible d'intégrer du JavaFX, l'essentiel semble plutôt reposer sur SWT.

Ca tire peut être un autre débat mais pourquoi justement les derniers clients lourds "made in Java" reposent plutôt sous Eclipse RCP ? Est-ce à cause des inconvénients qu'on vient de lister sur JavaFX ou plutôt le principe de création d'une application Eclipse RCP jugé plus simple et plus modulaire ?

[Mickael_Istria]

En quoi n'est-il pas possible de réutiliser des compétences et des pans de code au sein d'une application lourde ?

Je pense que c'est plutot une affaire culturelle. Beaucoup de gens qui ne connaissent pas forcement l'histoire de l'IT de ces 20 dernieres annees pensent qu'il y a plus des reutilisabilite dans les technos JS et NPM. Quand on connait Java et JS, on sait que c'est faux, mais pour beaucoup, le pli est pris et ils sont convaincus que l'ecosysteme JS est superieur a celui Java.

La raison pour laquelle les client lourds tendent a se rarefier au profit de technos basees sur du web tient essentiellement dans le fait que la part de marche des OS mobiles est devenu tres grande et que le "Java, build once, run everywhere" d'il y a 10 ans n'est plus vrai sur mobile. Alors que du JS oui: "write one, don't build, see bugs everywhere"

Ca tire peut être un autre débat mais pourquoi justement les derniers clients lourds "made in Java" reposent plutôt sous Eclipse RCP ? Est-ce à cause des inconvénients qu'on vient de lister sur JavaFX ou plutôt le principe de création d'une application Eclipse RCP jugé plus simple et plus modulaire ?

On peut faire du modulaire en OSGi ou autre avec JavaFX avec OSGi. D'ailleurs, le project e(fx)clipse fait un IDE base sur Eclipse mais en JavaFX, avec de la modularite.
RCP se place un cran au dessus d'une lib graphique (SWT): Il vient avec des concepts de workbench, de vues qu'on peut fermer/deplacer, de services globaux de selection... qui correspondent encore bien aux besoins des grosses applis. Cette couche n'est pas presente en JavaFX a ce que je sache, et la reimplementer demanderait beaucoup beaucoup d'energie.
RCP n'est pas le plus simple, mais quand on veut faire des grosses interfaces avec beaucoup de fonctionnalites un peu compliques, ca reste le plus adapte je pense.

[Logan Mauzaize]

En quoi n'est-il pas possible de réutiliser des compétences et des pans de code au sein d'une application lourde ?

Parce que les applis sont d'abord codés pour le Web ou le mobile hybride, donc dans un écosystème JS. Le client lourd est devenu secondaire pour beaucoup.

Ca tire peut être un autre débat mais pourquoi justement les derniers clients lourds "made in Java" reposent plutôt sous Eclipse RCP ? Est-ce à cause des inconvénients qu'on vient de lister sur JavaFX ou plutôt le principe de création d'une application Eclipse RCP jugé plus simple et plus modulaire ?

Ce sont généralement des applications business historiques. Eclipse RCP offre plein de service comme la modularité (plugin, feature, etc.), la gestion des mises à jours et du déploiement (ex : p2), la customization de l'IHM (raccourcis, docking, maximisation d'une vue, nouvelle fenêtre, perspective, etc.) et sûrement plein d'autres choses. Cependant le framework natif pour le graphisme c'est SWT et non JavaFX. Je sais qu'il est possible d'intégrer des composants JavaFX dans SWT mais je n'en connais pas les limites. De toutes façons, les personnes ayant accumulé de la compétence SWT et celle-ci étant obligatoire, il y a peu de raison technique d'ajouter un nouvel élément dans la stack.

Netbeans platform offrait les mêmes fonctionnalités (à ma connaissance) mais j'ai vu très peu de projet dessus. En réalité un seul (hors IDE) contre une dizaine pour Eclipse RCP.

D'ailleurs pour en revenir à l'écosytème JS, c'est bien pour les mêmes raisons qu'Electron rencontre un petit succès.

Je pense que c'est plutot une affaire culturelle. Beaucoup de gens qui ne connaissent pas forcement l'histoire de l'IT de ces 20 dernieres annees pensent qu'il y a plus des reutilisabilite dans les technos JS et NPM. Quand on connait Java et JS, on sait que c'est faux, mais pour beaucoup, le pli est pris et ils sont convaincus que l'ecosysteme JS est superieur a celui Java.

La réutilisation côté JS pour l'aspect client est bien plus immédiate vu qu'on reste sur le même domaine : la présentation (mobile, web ou lourd). En Java, c'est du backend VS frontend, c'est déjà plus compliqué ! Bien que RMI et les EJB soient plus anciens, ou même GWT. On ne peut clairement pas comparer à ce que propose Meteor. Je suis adepte d'aucunes de ces technos, étant partisan du couplage lâche dans les composants d'une architecture

La raison pour laquelle les client lourds tendent a se rarefier au profit de technos basees sur du web tient essentiellement dans le fait que la part de marche des OS mobiles est devenu tres grande et que le "Java, build once, run everywhere" d'il y a 10 ans n'est plus vrai sur mobile. Alors que du JS oui: "write one, don't build, see bugs everywhere"

C'est pas "debug everywhere" ?
Le "don't build" n'est plus vrai si les tests sont suffisants (bon ok il n'y a que dans les teams matures que ca existe) mais aussi avec les langages transpilés (Typescript, Ceylon, Kotlin, etc.). Un mauvais "projet" (équipe, gestion, etc.) reste un mauvais projet peu importe les technologies employées.

[sbeex]

Pensez-vous que JavaFX peine à s'implanter ?

C'est un fait eclipse ne l'utilise pas, intelliJ non plus et bon nombre d'application existante déjà avant javafx ne vont pas migrer de si tôt... malgré que la lib apporte son lot de nouveautés c'est certains.

Pensez-vous que le monde Desktop n'a pas d'avenir contrairement aux applications Web ?

Dans le cas de Java oui. Le web permet de faire des GUI beaucoup plus adaptées aux besoins actuels (multi plateforme multi devices, etc.)

De plus communiquer avec du hardware en java... oui on peut certes. Mais d'autres languages semblent plus appropriés. Donc je dirais que vu que les applications de gestions vont bouger sur des plateforme web pour être disponible sur tablette et smartphone plus facilement -> java desktop est en fin de vie oui (mais ca n'engage que moi )

Qu'est-ce qu'il manque à JavaFX pour réellement s'imposer ?
Des composants élémentaires pour commencer...

On doit sans cesse construire des choses qui existent déjà dans Swing

J'ai réalisé une application dans l'esprit d'un tableur excel. hum... la première colonne pour la griser façon excel c'était la croix et la bannière et la communauté la aoutur est pratiquement inexistante car sur swing..

Ca va être très dur de tuer swing à mon avis.

[abriotde]

Le problème de JavaFX c'est en grande partie que ce soit du Java sous Oracle. Tant que Java était sous tutelle de Sun, tous y accourait car on connaissait l'esprit ouvert de Sun. Depuis que Sun à été racheté les projets tentent de prendre leur indépendance connaissant l'esprit belliqueux d'Oracle. Or justement la licence de JavaFX (je ne sais plus trop pourquoi) est très ambigüe et donc risquée. Les projets tentent de ne garder que le socle réellement Open-Source de Java surtout, bien sûr, les projets Open-Source comme Eclipse.

[autran]

Oracle n'investira plus jamais sur JavaFX ni sur aucune autre techno client lourd car ça n'est pas opportun pour cet éditeur et ça ne le sera jamais.
En effet, 99,99% des clients lourds Swing ou JavaFX s’exécutent sur des postes de travail Windows. Et dans cet univers, l’écosystème Microsoft Windows et son langage C# sont juste indétrônables.

[Mickael_Istria]

Oracle n'investira plus jamais sur JavaFX ni sur aucune autre techno client lourd car ça n'est pas opportun pour cet éditeur et ça ne le sera jamais.
En effet, 99,99% des clients lourds Swing ou JavaFX s’exécutent sur des postes de travail Windows. Et dans cet univers, l’écosystème Microsoft Windows et son langage C# sont juste indétrônables.

Est-ce que tu as des sources, notamment pour le 99.99% ? Pour Eclipse IDE en tout cas, c'est a peu pres 80% windows, 10% Linux et 10% mac.
Pour rappel, IBM (utilisateur massif de clients lourds Java, pour beaucoup du Eclipse RCP) a demarre l'an dernier un programme d'adoption de Mac comme station de travail sur Mac en ciblant 20% de leur parc sous mac si je me souviens bien de confessions du createur de SWT. Et aussi, la progression de Linux sur desktop, bien qu'elle reste lente, continue. Du coup, quand on voit ce genre de tendances, les avantages du Java sur desktop semblent mieux convenir a la mouvance actuelle et future que d'adopter C# corps et ame.

[marc.collin]

Parce que les applis sont d'abord codés pour le Web ou le mobile hybride, donc dans un écosystème JS. Le client lourd est devenu secondaire pour beaucoup.
Netbeans platform offrait les mêmes fonctionnalités (à ma connaissance) mais j'ai vu très peu de projet dessus. En réalité un seul (hors IDE) contre une dizaine pour Eclipse RCP.

d'après les applications montré sur leur site, la platforme netbeans est utilisé dans le domaine bancaire et le domaine de la santé.

[Mickael_Istria]

d'après les applications montré sur leur site, la platforme netbeans est utilisé dans le domaine bancaire et le domaine de la santé.

Pour toutes les plateformes, qu'elles soient client lourds ou legers, tu peux trouver des exemples dans le domaine bancaire ou le domaine de la sante

[autran]

Salut Mickael,

99% est une figure de style pour dire que les appli Swing ou JavaFX que j'ai vu ou que j'ai écrites tournaient toutes sur windows chez les clients.

Cette réalité vient de la nature du parc de stations chez les clients non informaticiens et non scientifiques qui est presque totalement windows (hors medecins sous mac )
Je mets donc les utilisateurs d'éclipse, dont je fais partie, hors du périmètre.

Par ailleurs je ne voudrait pas que ma réponse soit interprétée comme du Java Bashing. Je suis d'ailleurs convaincu que C# est une photocopie de JAVA inventée 3 ans plus tard par Microsoft.

[Jitou]

JavaFX est définitivement un remplaçant de Swing, il est plus cohérent car il ne dérive pas de sous couches historiques, il offre un panel de composants riches et bien suffisant pour 90% des usages en application de gestion. Cette API arrive malheureusement trop tard sur le marché car depuis les frameworks Web sont passés par là et notamment la pléthores de framework JS qui selon moi n'est pas un progrès (mais c'est un autre débat). Aujourd'hui JavaFX serai encore adapté pour réaliser les nombreuses application mono-utilisateur que nous développons encore, plutôt que de proposer systématiquement la grosse artillerie : server d'application centralisé, VM, nouveaux "clients lourd" javascript.

[BugFactory]

Je travaille en ce moment sur une application JavaFX qui vient d'entrer en qualification. Pour ce que ça vaut, voici un mini retour d'expérience.
Les +
- Meilleure API que ses prédécesseurs. Facile à apprendre et à utiliser, code lisible et surtout, on obtient le comportement auquel on s'attend.
- SceneBuilder est pratique pour faire la mise en page.
- J'ai facilement pu intégrer JavaFx à Spring pour utiliser l'inversion de contrôle.
- Aucun problème de performance.
- Le support des lambda dans Java 8 est un vrai plus pour le développement des clients lourds, quel que soit la librairie.

Les -
- Peu de composants disponibles.
- Il est difficile d'intégrer des composants personnalisés à SceneBuilder, surtout si ils font partie du projet.
- Le composant preloader fourni (pour faire un écran de chargement) est trop limité, j'ai dû écrire le mien.
- Il y a un outil pour créer un installateur qui installe l'application avec une JVM embarquée et un lanceur sous forme d'exécutable, mais il manque d'options. J'ai du le remplacer par Launch4j et Inno Setup.

+ ou - selon votre projet
- JavaFx ne gère que l'interface. Je l'ai intégré à Spring pour le reste. Si vous voulez une solution tout en un, Eclipse RCP est peut-être un meilleur choix.

Notez qu'il ne s'agit que de mon expérience sur ce projet, pas d'une analyse globale de JavaFx. J'ai déjà utilisé Swing et Eclipse RCP avant, mais c'était il y a quelques années.

Dans notre cas, l'un des facteurs décisifs pour le choix de Java + JavaFx a été que nous avons déjà acquis une expertise Java pour le web, et que nous n'avons pas d'autres clients lourds. Choisir JavaFx nous permettait de créer cette application avec un effort de formation minimal. Sans ça, on se serait probablement tourné vers C++ ou C# pour éviter d'avoir à fournir une JVM embarquée, qui ajoute près de 50Mo à l'installateur.

J'espère que ce retour peut aider à éclairer cette discussion. Pour revenir à la question principale, à mon avis, JavaFx mérite bien d'être considéré comme le remplaçant de Swing. Mais il reste encore du travail. Comme j'ai pu le vérifier par moi-même, il faudrait un plus grand choix de composants et certains outils manquent d'options. A ce stade, la question est le calendrier des évolutions prévues. Oracle a l'air d'hésiter sur le sujet. D'un coté, il est incontestable qu'un travail de qualité a été fait. De l'autre, le langage Java lui-même est plus populaire pour le web que pour les clients lourds, JavaFx n'est pas forcément la priorité.

[yozine]

Un autre aspect à prendre en compte dans le débat est aussi la compétence, et la disponibilité de celle-ci.

À ce jour, il devient de plus en plus difficile de trouver des développeurs, et architectes, qui sont sont réellement capables de faire du bon client lourd. C'est techniquement moins accessible que de faire du client léger web. À ma connaissance, si je prend l'exemple des plugins avec points d'extension Rcp, c'est souvent mal connu voire mal implémenté.

Mais dans le domaine des banques et assurances, le client lourd reste un incontournable. Il faudra bien encore 10 ans avant que les projets de migration sur de la technologie client léger qui sont aujourd'hui à l'étude soient opérationnels.

On entend encore parler de COBOL et autres vieilles technos...

Mais pour revenir à JavaFX, il est vrai qu'il n'apporte peut-être rien de plus que swt et Swing, alors pourquoi migrer ?

[Mickael_Istria]

Juste pour rappel, client lourd vs client leger, quand on voit que l'appli Slack coute 200MB de RAM (soit aurant qu'un Eclipse RCP deja assez baleze), on a du mal a voir ce qui justifie lourd vs leger. C'est juste un client "natif" vs un client HTML.