J'ai un projet de 4 ans qui est écrit en Swing + SwingX. Actuellement, il est toujours vivant et continue de donner des coups de pied.
Cependant, à mesure que de nouvelles demandes de fonctionnalités liées à l'interface utilisateur arrivent (par exemple, une table arborescente triable), je commence à ressentir la difficulté à remplir les demandes. Cela est d'autant plus vrai qu'il n'y a pas de développement actif autour du projet SwingX.
De plus, je peux difficilement trouver un cadre Java GUI bon, mais activement maintenu / développé / évolutif.
Je me demandais, est-ce que l'un des développeurs de Swing ressent la même chose? Avez-vous commencé à migrer votre projet Swing vers un framework GUI développé beaucoup plus actif, comme JavaFX?
Réponses:
Je passe personnellement à JavaFX (2.1+, pas à l'ancienne version 1.x bizarre avec le langage de script méchant). Le nouveau JavaFX n'est pas parfait à 100%, mais c'est déjà une vue sacrément plus agréable à utiliser que Swing, je vois un avenir raisonnable pour lui (surtout compte tenu du moteur Webkit intégré).
la source
Je me pose souvent la même question, mais je ne pense pas que je migrerais des projets existants vers JavaFX. Du moins pas pour l'instant, et pas pour des projets de moyenne à grande envergure. Cependant, je considérerais JavaFX pour de nouveaux projets, et envisagerais à nouveau une migration à l'avenir et réévaluerais la question en fonction des progrès de JavaFX.
Pour le moment, mes préoccupations sont les suivantes:
Immaturité
Oui, nous allons bientôt passer à la 3.0, mais cela ne fait pas si longtemps et a encore subi des changements majeurs. Donc, pour les logiciels d'entreprise volumineux et peu enclins à prendre des risques, c'est un endroit relativement sensible.
Performance
Je n'ai pas vu suffisamment de données matérielles sur les différences de performances.
Widgets et composants
Je n'ai pas vu assez de gain dans les nouveaux composants. Cela peut être lié à l'immaturité, je suppose. Je ne sais pas encore à quel point ils peuvent être étendus et composés, contrairement à Swing.
Dans l'ensemble, je suppose que les données réelles sur les avantages sont ce qui me manque pour être pleinement convaincu par JavaFX.
D'autre part, Swing est éprouvé et testé. Oui, l'API est maladroite et invoquer l'auto-complétion dans votre IDE sur un objet Swing comme le JTextPane le fera pleurer et pleurer pour sa maman, mais, si vous êtes suffisamment informé, vous pouvez créer de superbes interfaces utilisateur avec Swing, cela fonctionnent bien (je n'ai jamais acheté le sophisme Swing-has-bad-performance, voir les anciens articles de blog de Romain Guy sur les blogs de Sun) et vous permettent de faire des choses assez soignées.
Donc, avant de changer quoi que ce soit, je vous recommande d'essayer d'abord un petit prototype, et peut-être d'essayer de porter certaines des boîtes de dialogue de votre application et de voir comment cela se passe.
la source
J'ai fait beaucoup de JavaFX maintenant et je le préfère à Swing. La structure du graphe de scène est différente de ce à quoi vous êtes habitué avec Swing, mais elle offre tellement d'améliorations. L'API est agréable à travailler, elle est rafraîchissante.
Il y a tellement plus que vous pouvez faire avec, multimédia, animation, navigation sur le Web. Vous pouvez par exemple créer une application Google Maps en quelques lignes de code, en incorporant html5 et javascript.
Il serait inclus dans le runtime Java 8, ce qui signifierait le remplacement définitif de Swing comme framework d'interface utilisateur par défaut
@Migration : vous devez commencer par isoler les parties de votre application qui peuvent être converties en JavaFX. L'interopérabilité Swing-JavaFX 2 est une grande chose, vous pouvez utiliser le javafx.embed.swing.JFXPanel pour incorporer votre élément JavaFX. Voir swing-fx-interoperability . (Pour être complet, vous pouvez également intégrer SWT.)
la source
Swing est en train de devenir une technologie héritée, ou l'est déjà. Cependant, il est assez bon dans ce qu'il fait et ne disparaîtra pas dans un avenir prévisible, donc je ne vois aucune raison de s'en éloigner, en particulier si l'on y a déjà investi. Le logiciel JIDE fabrique de bons composants Swing (commerciaux) pour remplacer ce qui manque dans le Swing standard. Par exemple, la treetable triable est dans leurs grilles hors de la boîte.
la source
Bien que les nouvelles versions de JavaFX semblent très impressionnantes, je doute que cela vaille la peine de faire une migration complète, sauf si vous êtes prêt à investir beaucoup de temps / d'efforts / d'argent dans une refonte complète de l'interface graphique.
La balançoire peut avoir ses caprices et montre son âge, mais elle présente également certains avantages:
En fin de compte, s'il n'est pas cassé, pourquoi le réparer?
Bien sûr, pour un nouveau projet, j'examinerais très sérieusement JavaFX, Android et / ou une interface graphique Web (peut-être avec quelque chose comme Vaadin).
la source
Je suis dans la même position que l'OP - ayant des applications swing héritées mais ayant besoin d'implémenter de nouveaux idiomes et interfaces qu'il ne supporte pas nativement. La plus grande de ces applications a été refactorisée plusieurs fois pour diverses raisons (améliorer la modularité, une meilleure structure MVC et de répartition des événements, etc.), donc je ne suis pas complètement opposé à la réécriture du code de l'interface utilisateur. J'ai donc longuement réfléchi à la question.
Cependant, certaines choses ne peuvent pas être résolues avec Swing sans investir beaucoup plus de temps et d'efforts sur ce qui est essentiellement une technologie héritée. Par exemple, autres que les simples événements de souris, les nouveaux appareils à écran tactile et ne sont pas pris en charge par Swing lui-même. Fournir un composant de navigateur basé sur Swing est également gênant ou coûteux, et dans mon cas, l'approche javafx-in-swing n'est pas une option car elle complique la gestion des événements d'interface utilisateur de manière non triviale.
Je pense qu'elle a été ancienne et fidèle en son temps, et si votre plate-forme est aussi immuable que votre base de code - respectez-la, évidemment. Mais pour qu'une application évolue vers de nouveaux cas d'utilisation plus contemporains, JavaFX 2+ sera probablement le moyen d'avancer dans mon cas.
En guise de remarque: le seul défaut de Swing que j'aurais aimé avoir disparu dans jfx - mais je ne l'ai pas fait - est l'approche d'un fil à tous les règles pour la distribution d'événements UI. Toute interface utilisateur non triviale a besoin de plusieurs threads pour garder l'interface utilisateur nette et réactive, et laisser entièrement au développeur de l'application le soin de tomber sur les mêmes pièges si facilement est un manque dans l'API IMHO.
la source
J'ai une grande expérience de l'utilisation de RCP dans de grandes applications de bureau. Il a essentiellement commencé comme une abstraction de la couche GUI d'Eclipse et a parcouru un long chemin depuis lors. Au lieu de Swing, qui est basé sur AWT, RCP s'appuie sur JFace, qui à son tour est basé sur SWT. Il vous permet de développer des applications et d'utiliser les concepts GUI qu'Eclipse utilise lui-même (vues, éditeurs, perspectives, assistants, etc.). Il est très évolutif et, comme Eclipse lui-même, est constamment amélioré.
Cependant, je n'ai jamais migré un projet existant de Swing vers RCP; J'imagine que cela prendrait un certain temps pour envelopper votre tête autour des différents paradigmes et si vous n'avez pas bien séparé votre modèle et les couches de vue, vous aurez certainement du mal. Mais puisque vous avez posé des questions sur des choses comme les tables d'arbre triables, RCP est parfait pour cela.
Si vous souhaitez poursuivre cette recherche, vous pouvez essayer le didacticiel de Lars Vogel ou jeter un œil à quelques exemples de projets open source ou de projets commerciaux qui utilisent RCP.
la source
pas vrai, encore une fois ce projet est vivant,
blablabla une fois que SwingX a perdu les subventions de Sun (lors de l'acquisition par Oracle), les gens de SwingX sont allés construire JavaFX
pas de Swing ne concerne pas le Framework mais le Look and Feel
Les cadres sont destinés aux utilisateurs non techniques (MsAccess est peut-être le meilleur exemple pour le cadre GUI)
mais si vous voulez construire une vraie application, vous avez de solides connaissances sur Swing et overriden est également venu de Framework,
exemple drôle Netbeans a construit_in Swing Framework basé sur JSR296, mais il n'est pas possible de changer directement l'icône JFrames,
aucune raison
même chose pour la migration vers Java7, peut-être quand y sera-t-il Java7.15 - 17
Je compare JavaFx à Nimbus, le développement s'est terminé / abandonné quelque part dans la première moitié
désolé je ne suis pas développeur je suis seulement Java & Swing Fan
la source