Application de bureau Java: SWT vs Swing [fermé]


Je suis développeur web chez day et je pense à construire ma première vraie application de bureau. L'idée est de construire un outil qui automatise une tâche très répétitive dans une application web où aucune API n'est disponible.

Je sais que je veux utiliser Java. Je l'ai déjà utilisé pour des trucs Web, je connais assez bien la syntaxe et je veux que l'application soit aussi simple que possible.

Où je ne suis pas si sûr, c'est si je dois utiliser SWT ou Swing. Comme mon public principal utilise Windows, je veux le regarder aussi natif que possible là-bas. Linux et Mac devraient fonctionner, mais les regards ne sont pas si importants ici.

Alors, quels sont les arguments pour et contre chaque framework UI, Swing ou SWT?

Merci.

PS: Je développe sur Windows en utilisant Eclipse. Mais pensait à jouer avec Netbeans.

Author: janpio, 2010-02-21

10 answers

Pour Swing:

  • partie de la bibliothèque java, pas besoin de bibliothèques natives supplémentaires
  • fonctionne de la même manière sur toutes les plateformes
  • Éditeur d'interface graphique intégré dans Netbeans et Eclipse
  • bons tutoriels en ligne par Sun / Oracle
  • Pris en charge par les extensions java officielles (comme java OpenGL)

Les Inconvénients De La Balançoire:

  • L'apparence native peut se comporter différent du vrai natif système.
  • composants lourds (natif/awt) masquer swing components, pas un problème la plupart du temps car l'utilisation de composants lourds est plutôt rare

Pour SWT:

  • utilise des éléments natifs lorsque cela est possible, donc toujours un comportement natif
  • pris en charge par eclipse, éditeur gui VEP (VEP prend également en charge Swing et AWT)
  • grand nombre d'exemples en ligne
  • a un pont awt/swt intégré pour permettre l'utilisation de composants awt et swing

Contre SWT:

  • nécessite des bibliothèques natives pour chaque système pris en charge
  • peut ne pas prendre en charge tous les comportements sur tous les systèmes en raison de ressources utilisées (options d'indice)
  • gestion des ressources natives, alors que les composants natifs seront souvent éliminés avec leur parent, d'autres ressources telles que les polices doivent être libérées manuellement ou enregistrées en tant qu'écouteur dispose dans un composant pour une libération automatique.
 148
Author: josefx, 2014-04-03 11:35:39

Une chose importante à considérer est que certains utilisateurs et certains revendeurs (Dell) installent une machine virtuelle 64 bits sur leur Windows 64 bits, et vous ne pouvez pas utiliser la même bibliothèque SWT sur les machines virtuelles 32 bits et 64 bits.

Cela signifie que vous devrez distribuer et tester différents packages selon que les utilisateurs ont une machine virtuelle Java 32 bits ou 64 bits. Voir ce problème avec Azureus, par exemple, mais vous l'avez aussi avec Eclipse, où à ce jour les builds sur la page de téléchargement avant ne s'exécutent pas sur un 64 peu de VM.

 62
Author: Ludovico Fischer, 2010-02-21 15:26:53

Pro swing:

  • Le plus grand avantage de swing IMHO est que vous n'avez pas besoin d'expédier les bibliothèques avec votre application (ce qui évite douzaine de MO(!)).
  • L'aspect natif est beaucoup mieux pour le swing que dans les premières années
  • la performance est comparable à swt (swing n'est pas lent!)
  • NetBeans offre Matisse comme un constructeur de composants confortable.
  • L'intégration des composants Swing dans JavaFX est plus facile.

Mais en bout de ligne je ne suggérerait pas d'utiliser swing " pur " ou swt ;-) Il existe plusieurs cadres d'application pour swing/swt out. Regardez ici. Les plus grands joueurs sont netbeans (swing) et eclipse (swt). Un autre cadre agréable pourrait être griffon et un bel "ensemble de composants" est pivot (swing). Griffon est très intéressant car il intègre beaucoup de bibliothèques et non seulement swing ; aussi pivot, swt, etc

 23
Author: Karussell, 2010-02-23 22:01:02

J'utiliserais Swing pour plusieurs raisons.

  • Il a été autour plus longtemps et a eu plus d'efforts de développement appliqués à il. Par conséquent il est probablement plus caractéristique complet et (peut-être) a moins de bugs.

  • Il y a beaucoup de documentation et autres conseils sur la production applications performantes.

  • Il semble comme les changements à Swing se propagent à toutes les plates-formes simultanément tandis que les modifications apportées à SWT semblent apparaître sur Windows d'abord, puis Linux.

Si vous souhaitez créer une application très riche en fonctionnalités, vous pouvez consulter le NetBeans RCP (Rich Client Platform). Il y a une courbe d'apprentissage, mais vous pouvez mettre en place de belles applications rapidement avec un peu de pratique. Je n'ai pas assez d'expérience avec la plate-forme Eclipse pour porter un jugement valide.

Si vous ne voulez pas utiliser le RCP entier, NetBeans a également de nombreux composants utiles qui peuvent être retirés et utilisés indépendamment.

Un autre mot de conseil, regardez dans différents gestionnaires de mise en page. Ils m'ont fait trébucher pendant longtemps quand j'apprenais. Certains des meilleurs ne sont même pas dans la bibliothèque standard. Les outils MigLayout (pour Swing et SWT) et JGoodies Forms sont deux des meilleurs à mon avis.

 13
Author: clartaq, 2010-02-21 16:24:17

Je choisirais swing juste parce que c'est "natif" pour java.

Plus, jetez un oeil à http://swingx.java.net/.

 10
Author: zeroed, 2013-07-31 03:58:56

Pour vos besoins, il semble que l'essentiel sera d'utiliser Swing car il est légèrement plus facile de commencer et pas aussi étroitement intégré à la plate-forme native que SWT.

Swing est généralement une valeur sûre.

 8
Author: Yuval Adam, 2010-02-21 14:47:15

Question intéressante. Je ne connais pas trop SWT pour m'en vanter (contrairement à Swing et AWT) mais voici la comparaison faite sur SWT/Swing/AWT.

Http://www.developer.com/java/other/article.php/10936_2179061_2/Swing-and-SWT-A-Tale-of-Two-Java-GUI-Libraries.htm

Et voici le site où vous pouvez obtenir un tutoriel sur fondamentalement n'importe quoi sur SWT (http://www.java2s.com/Tutorial/Java/0280__SWT/Catalog0280__SWT.htm )

J'espère que vous prenez une bonne décision (s'il y a sont bonnes décisions dans le codage)... :-)

 6
Author: Buhake Sindi, 2010-02-21 14:52:20

Si vous envisagez de créer des applications fonctionnelles complètes avec plus d'une poignée de fonctionnalités, je vous suggérerai de passer directement à l'utilisation d'Eclipse RCP comme framework.

Si votre application ne devient pas trop grande ou si vos exigences sont trop uniques pour être traitées par un cadre commercial normal, vous pouvez sauter en toute sécurité avec Swing.

À la fin de la journée, je vous suggère d'essayer les deux technologies pour trouver celle qui vous convient le mieux. Comme Netbeans vs Eclipse vs IntelliJ, il n'y a pas le réponse correcte absolue ici et les deux cadres ont leurs propres inconvénients.

Pro Swing:

  • plus d'experts
  • plus de type Java (presque pas de champ public, pas besoin de disposer sur la ressource)

Pro SWT:

  • plus natif OS
  • plus rapide
 4
Author: nanda, 2010-02-21 15:48:47

Une chose à considérer: Screenreaders

Pour certaines raisons, certains composants Swing ne fonctionnent pas bien lors de l'utilisation d'un screenreader (et du Java AccessBridge pour Windows). Sachez que différents lecteurs d'écran entraînent un comportement différent. Et d'après mon expérience, le SWT-Tree fonctionne beaucoup mieux que le Swing-Tree en combinaison avec un screenreader. Ainsi, notre application a fini par utiliser à la fois des composants SWT et Swing.

Pour distribuer et charger la bibliothèque SWT appropriée, vous pourrait trouver ce lien utile: http://www.chrisnewland.com/select-correct-swt-jar-for-your-os-and-jvm-at-runtime-191

 4
Author: incomudro, 2013-04-23 09:27:28

SWT a été créé en réponse à la lenteur du Swing au tournant du siècle. Maintenant que les différences de performances deviennent négligeables, je pense que Swing est une meilleure option pour vos applications standard. SWT / Eclipse a un cadre agréable qui aide avec beaucoup de code de plaque de chaudière.

 3
Author: Oliver Watkins, 2013-02-28 15:51:50