JavaFX remplace-t-il Swing ?

Bonjour,
après avoir suivi un Mooc d'introduction à la programmation objet en java, ou j'ai pu decouvrir les bases de la programmation objet j'ai souhaité aller plus loin et m'attaquer aux interfaces utilisateurs.
Je me suis naturellement orienté vers Swing pour réaliser mes premières applications.
Mais je viens de découvrir que java fx était appelé à remplacer swing.
Est il donc nécessaire de me former vraiment à cet outil ou dois je plutot apprendre java fx ?
j'ai regardé les faq sur java fx mais je n'ai pas bien compris si java fx couvrait déjà l'ensemble des fonctionnalités des swing ou si cela était en chantier merci pour votre réponse.
Il est très difficile pour un autodidacte de savoir quels sont les outils nécessaires auxquels il faut se former en priorité.
Je profite de ce post pour remercier l'ensemble des contributeurs de ce forum qui m'est très utile et que je consulte à chaque fois que j'ai un problème. j'y trouve pratiquement à tous les coups la solution à mon problème dont le sujet à souvent été traité.

Bonjour,

Je ne crois pas que Swing et AWT vont disparaître de si tôt. Il me semble que Java FX est installé en complément à Java (dans les plus récentes versions d'Oracle, à partir de JDK 7u6, Java FX est bundler avec).

De ce que j'ai pu comprendre quand j'ai commencé à regarder JavaFX, le but était de faire des interfaces plus interactives avec des animations et tout. Cette librairie a débuté quand on voyait Flex prendre d'assaut les applications webs. Maintenant, Flex est délaissé pour HTML5.

Le plus gros problème de Swing, c'est qu'il est laid par défaut :) . Le deuxième problème de n'importe quel GUI en Java, c'est qu'il faut une JVM locale pour rouler l'application. Il faut par la suite installer toutes les mises à jour de sécurités, etc. C'est pourquoi en entreprise, c'est mieux d'utiliser Java avec HTML5. Comme je ne sais pas quel genre d'application tu veux faire, je vais supposer que tu veux vraiment un GUI.

Reste à savoir qui va rouler cette application: Swing est un standard qui se retrouve dans toutes les JVM ; JavaFX est pratiquement juste dans celle d'Oracle. Par exemple, sous linux, la OpenJDK ne l'a pas encore. Ça commence à se développer.

C'est donc à toi de voir si tu veux rouler partout ou si tu es prêt à rouler juste sur du plus récent.

merci pour ces éclaircissements.

Depuis JavaFX 2.2, les runtimes sont tout le temps disponibles avec le JDK (mais il fallait faire une manip pour les utiliser). Depuis JavaFX 8 / JDK8 les runtimes sont tout le temps sur le CLASSPATH donc il n'y a rien besoin de faire pour les utiliser.

Officiellement, JavaFX est effectivement destiné a totalement remplacer Swing et AWT dans le futur. Cependant effectivement, ça décolle assez doucement pour ne pas dire faiblement puisque l’écosystème Swing et AWT est énorme d'une part et d'autre part car le hype du moment c'est HTML5 a toutes les sauces (y compris quand ça ne se justifie pas et n'est pas adapté pour). Même Oracle ne se positionne franchement pour pousser JavaFX en avant comme ils pourraient le faire puisqu'ils ont eux-même un framework HTML5, Oracle ADF Mobile (devenu depuis Mobile Application Framework (MAF)) sur lequel ils font bien plus de pub.

Comme pour tous les autres (Flex, WPF, etc.) on ne sait pas trop ce qu'il adviendra réellement des clients lourds natifs dans les années qui viennent face a HTML5. Seulement voila, comme James Gosling (le createur de Java) l'a si bien dit lui-même, "There are plenty of things HTML is not good at!" (il parlait d'un logiciel Swing basé sur World Wind de la NASA destiné a effectuer le tracking des robots autonomes que la compagnie Liquid Robotics pour laquelle il est consultant ces dernières années a largué dans l'ocean Pacifique)

Cependant, pour le moment, sauf un retour en arrière peu probable (on est jamais a l'abri d'une décision commerciale d'Oracle bien sur), JavaFX continuera à évoluer mais pas AWT ni Swing. Pour ces deux-la, c'est fini, ils sont feature-frozen (et ce depuis 2008 déjà !) et ne se contenteront que de correctifs de bugs. Ils sont toujours disponibles et accessible et, pour le moment, Oracle n'a jamais indiqué aucune volonté de les voir disparaitre. Et bien sur il existe toujours toutes sortes de libs tierces qui sont développées même encore de nos jours. Et bien sur on peut interfacer Swing avec JavaFX et JavaFX avec Swing (et donc avoir le meilleur des deux mondes même si ça demande plus de boulot pour faire dialoguer les deux bouts ensemble et avoir une apparence unifiée).

Comme le reste de la plateforme, Swing et AWT vont être modularisés séparément de manière à permettre de ne plus les avoir forcement sur toutes les plateformes. Ainsi, ils font partie du profil "Full SE API", mais pas des profils compact1, compact2 ou compact3.

JavaFX étant plus récent, il est est déjà modularisé (et pas uniquement en temps que grosse lib "JavaFX" monolithique mais en tant que plusieurs sous entités diverses) n'est pas indiqué sur cette liste (aucune idée de quand l'article date). En effet, normalement le profil compact3 ne contient rien de graphique, cependant, sur Raspberry Pi, JavaFX est accessible et utilisable dans le profil compact3 mais dans une version "Embedded" un peu plus réduite que la version "full JRE" disponible sur PC de bureau (pour le moment : pas de 3D, pas de support des média, pas de support du HTML5).

EDIT - le problème des versions de la JVM est réglé depuis quelques années déjà : désormais Oracle pousse pour les JVM embarquées dans les apps. Ce qui est de toute manière la seule et unique possibilité pour permettre de distribuer des apps dans les app store desktop et mobiles d'Apple, Microsoft et autres... puisque ces applications doivent être auto-suffisantes et ne nécessiter aucune lib tierce pré-installée sur la plateforme cible pour fonctionner. Du coup, cela règle la plupart des problèmes de sécurité puisqu'une JVM embarquée n'a aucun lien avec le système ou les navigateurs web et n'est utilisée que par son application : c'est une JVM locale pas une JVM système. Une fois la modularisation de la plateforme finie, cela devrait également aussi réduire un peu la taille des JVM embarquées (qui actuellement font 50-60Mo par app... super quand le code de l'app elle-même est < 2Mo ).