+ Répondre à la discussion Actualité déjà publiée
  1. #1
    Responsable Java
    Avatar de Robin56
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juin 2009
    Messages
    4 702
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : juin 2009
    Messages : 4 702
    Points : 11 960
    Points
    11 960

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

    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 ?

  2. #2
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 858
    Points : 6 894
    Points
    6 894

    Par défaut

    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.
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  3. #3
    Responsable Java
    Avatar de Robin56
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juin 2009
    Messages
    4 702
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Architecte de système d'information

    Informations forums :
    Inscription : juin 2009
    Messages : 4 702
    Points : 11 960
    Points
    11 960

    Par défaut

    Citation Envoyé par Logan Mauzaize Voir le message
    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 ?

    Citation Envoyé par Logan Mauzaize Voir le message
    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 ?

  4. #4
    Membre chevronné
    Avatar de Mickael_Istria
    Homme Profil pro
    Développeur Expert Eclipse RCP
    Inscrit en
    juillet 2008
    Messages
    977
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Expert Eclipse RCP
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2008
    Messages : 977
    Points : 2 032
    Points
    2 032

    Par défaut

    Citation Envoyé par Robin56 Voir le message
    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.
    Tu fais du JEE/Web/Mobile dans Eclipse? Essaye JBoss Tools !
    Read my blog about Eclipse | Follow me on twitter

  5. #5
    Rédacteur/Modérateur
    Avatar de Logan Mauzaize
    Homme Profil pro
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 858
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 858
    Points : 6 894
    Points
    6 894

    Par défaut

    Citation Envoyé par Robin56 Voir le message
    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.

    Citation Envoyé par Robin56 Voir le message
    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.

    Citation Envoyé par Mickael_Istria Voir le message
    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

    Citation Envoyé par Mickael_Istria Voir le message
    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.
    Java : Cours et tutoriels - FAQ - Java SE 8 API - Programmation concurrente
    Ceylon : Installation - Concepts de base - Typage - Appels et arguments

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  6. #6
    Membre habitué
    Profil pro
    Ingénieur développement logiciels
    Inscrit en
    septembre 2011
    Messages
    80
    Détails du profil
    Informations personnelles :
    Localisation : Suisse

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : septembre 2011
    Messages : 80
    Points : 186
    Points
    186

    Par défaut

    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.

  7. #7
    Membre éclairé
    Homme Profil pro
    Développeur informatique
    Inscrit en
    juillet 2007
    Messages
    476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : juillet 2007
    Messages : 476
    Points : 751
    Points
    751

    Par défaut

    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.
    Tout ce que j'écris est libre de droits (Licence CC0) et je vous incite à faire de même.

  8. #8
    Rédacteur

    Avatar de autran
    Homme Profil pro
    Développeur Java
    Inscrit en
    février 2015
    Messages
    1 202
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2015
    Messages : 1 202
    Points : 7 202
    Points
    7 202
    Billets dans le blog
    71

    Par défaut

    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.
    Développeur Java/Python
    Site Web

  9. #9
    Membre chevronné
    Avatar de Mickael_Istria
    Homme Profil pro
    Développeur Expert Eclipse RCP
    Inscrit en
    juillet 2008
    Messages
    977
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Expert Eclipse RCP
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2008
    Messages : 977
    Points : 2 032
    Points
    2 032

    Par défaut

    Citation Envoyé par autran Voir le message
    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.
    Tu fais du JEE/Web/Mobile dans Eclipse? Essaye JBoss Tools !
    Read my blog about Eclipse | Follow me on twitter

  10. #10
    Membre confirmé
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    juin 2012
    Messages
    290
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur en génie logiciel
    Secteur : Finance

    Informations forums :
    Inscription : juin 2012
    Messages : 290
    Points : 565
    Points
    565

    Par défaut

    Citation Envoyé par Logan Mauzaize Voir le message
    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é.
    Ailler le courage de justifier vos -1.
    http://www.laboiteaprog.com/ - http://www.solutions-norenda.com/

  11. #11
    Membre chevronné
    Avatar de Mickael_Istria
    Homme Profil pro
    Développeur Expert Eclipse RCP
    Inscrit en
    juillet 2008
    Messages
    977
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Expert Eclipse RCP
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2008
    Messages : 977
    Points : 2 032
    Points
    2 032

    Par défaut

    Citation Envoyé par marc.collin Voir le message
    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
    Tu fais du JEE/Web/Mobile dans Eclipse? Essaye JBoss Tools !
    Read my blog about Eclipse | Follow me on twitter

  12. #12
    Rédacteur

    Avatar de autran
    Homme Profil pro
    Développeur Java
    Inscrit en
    février 2015
    Messages
    1 202
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2015
    Messages : 1 202
    Points : 7 202
    Points
    7 202
    Billets dans le blog
    71

    Par défaut

    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.
    Développeur Java/Python
    Site Web

  13. #13
    Membre averti
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2007
    Messages
    145
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : janvier 2007
    Messages : 145
    Points : 354
    Points
    354

    Par défaut

    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.

  14. #14
    Membre éprouvé
    Profil pro
    Inscrit en
    octobre 2005
    Messages
    833
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France

    Informations forums :
    Inscription : octobre 2005
    Messages : 833
    Points : 1 236
    Points
    1 236

    Par défaut

    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é.

  15. #15
    Membre régulier
    Inscrit en
    juin 2007
    Messages
    161
    Détails du profil
    Informations forums :
    Inscription : juin 2007
    Messages : 161
    Points : 109
    Points
    109

    Par défaut Compétences

    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 ?
    JAVA le dire a tout le monde

  16. #16
    Membre chevronné
    Avatar de Mickael_Istria
    Homme Profil pro
    Développeur Expert Eclipse RCP
    Inscrit en
    juillet 2008
    Messages
    977
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Expert Eclipse RCP
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2008
    Messages : 977
    Points : 2 032
    Points
    2 032

    Par défaut

    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.
    Tu fais du JEE/Web/Mobile dans Eclipse? Essaye JBoss Tools !
    Read my blog about Eclipse | Follow me on twitter

Discussions similaires

  1. [OL-2010] Déplacemment d'un mail lorsque son statut passe à LU
    Par ElGothiko dans le forum VBA Outlook
    Réponses: 2
    Dernier message: 14/05/2012, 09h17
  2. Réponses: 42
    Dernier message: 26/11/2009, 12h58
  3. Suite Nouvelle embauche : Peut on perdre son statut cadre ?
    Par nomade33 dans le forum Droit du travail
    Réponses: 4
    Dernier message: 08/09/2006, 10h38

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo