Application Java Desktop: SWT vs. Swing

Je suis développeur Web le jour et je pense à la création de ma première véritable application de bureau. L’idée est de créer 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 souhaite que l’application soit aussi simple que possible.

Je ne sais pas si je dois utiliser SWT ou Swing. Comme mon public principal utilise Windows, je veux le voir aussi natif que possible. Linux et Mac devraient fonctionner, mais les aspects ne sont pas si importants ici.

Alors, quels sont les arguments pour et contre chaque structure d’interface utilisateur, Swing ou SWT?

Merci.

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

    Pros Swing:

    • partie de la librairie java, pas besoin de librairies natives supplémentaires
    • fonctionne de la même manière sur toutes les plates-formes
    • Editeur graphique intégré dans Netbeans et Eclipse
    • bons tutoriels en ligne par Sun / Oracle
    • Pris en charge par les extensions officielles java (comme java OpenGL)

    Contre Swing:

    • L’aspect natif peut être différent du système natif réel.
    • les composants lourds (natifs / génériques) masquent les composants de balançoire, ce qui n’est pas un problème la plupart du temps, car l’utilisation de composants lourds est plutôt rare

    Pros SWT:

    • utilise si possible des éléments natifs, donc toujours un comportement natif
    • supporté par eclipse, éditeur gui VEP (VEP supporte aussi Swing et AWT)
    • grand nombre d’exemples en ligne
    • a un pont intégré awt / swt pour permettre l’utilisation de composants awt et swing

    Cons 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 des ressources natives utilisées (options de conseil)
    • la gestion des ressources natives, tandis que les composants natifs seront souvent éliminés avec leurs autres ressources parentales, par exemple, les fonts doivent être libérées manuellement ou enregistrées en tant que programme d’écoute de disposition pour un composant à libérer automatiquement.

    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 que vous ne pouvez pas utiliser la même bibliothèque SWT sur des machines virtuelles 32 bits et 64 bits.

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

    swing professionnel:

    • Le plus grand avantage du swing IMHO est que vous n’avez pas besoin d’expédier les bibliothèques avec votre application (ce qui évite des dizaines de Mo (!)).
    • L’apparence et la sensation natives sont bien meilleures pour le swing que dans les premières années
    • la performance est comparable à swt (le swing n’est pas lent!)
    • NetBeans propose 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érerais pas d’utiliser un swing ou un swt «pur» 😉 Il existe plusieurs frameworks d’application pour swing / swt out. Regardez ici Les plus gros joueurs sont netbeans (swing) et eclipse (swt). Un autre bon cadre pourrait être le griffon et un joli “ensemble de composants” est pivot. Griffon est très intéressant car il intègre de nombreuses bibliothèques et ne se contente pas de balancer ; également pivoter, swt, etc.

    Je voudrais utiliser Swing pour plusieurs raisons.

    • Cela a duré plus longtemps et des efforts de développement supplémentaires ont été déployés. Il est donc probable que d’autres fonctionnalités soient complètes et (peut-être) moins de bogues.

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

    • Il semble que les modifications apscopes à Swing se propagent simultanément à toutes les plates-formes alors que les modifications apscopes à SWT semblent apparaître d’abord sur Windows, puis sur Linux.

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

    Si vous ne souhaitez pas utiliser l’intégralité du RCP, NetBeans possède également de nombreux composants utiles pouvant être utilisés indépendamment.

    Un autre conseil, examinez différents gestionnaires de mise en page. Ils m’ont fait trébucher 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.

    Je choisirais le swing juste parce que c’est “natif” pour Java.

    De plus, consultez http://swingx.java.net/ .

    Pour vos besoins, il semble que le résultat final sera d’utiliser Swing car il est légèrement plus facile de démarrer avec et n’est pas aussi étroitement intégré à la plate-forme native que SWT.

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

    Question interessante. Je ne connais pas trop SWT pour s’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 pratiquement tout ce qui concerne SWT ( http://www.java2s.com/Tutorial/Java/0280__SWT/Catalog0280__SWT.htm )

    J’espère que vous prenez la bonne décision (s’il y a de bonnes décisions dans le codage) … 🙂

    Si vous envisagez de créer des applications entièrement fonctionnelles avec plus d’une poignée de fonctionnalités, je suggérerai de passer directement à l’utilisation d’Eclipse RCP en tant que framework.

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

    En fin de compte, 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 de réponse correcte absolue ici et les deux frameworks ont leurs propres inconvénients.

    Pro Swing:

    • plus d’experts
    • plus Java-like (presque pas de domaine public, pas besoin de se débarrasser des ressources)

    Pro SWT:

    • plus d’OS natif
    • plus rapide

    Une chose à considérer:

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

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

    SWT a été créé en réponse à la lenteur de 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 joli cadre qui aide avec beaucoup de code de plaque de chaudière.