Présentation audio/slide de SWT vs Swing

December 8th, 2004 par Freddy Mallet

Vous trouverez à l’adresse suivante une présentation relativement intéressante sur SWT. Malgré une neutralité de façade, on sent bien que le coeur de l’auteur (un certain Ben Galbraith) bascule du côté SWT du GUI. Pour rappel, SWT est une API totalement concurrente à Swing pour la création de GUI en Java. Historiquement cette API a vu le jour au sein du projet Eclipse en réaction principalement aux problèmes de lenteurs ‘inhérents’ à Swing. La partie graphique d’Eclipse s’appuie donc entièrement sur SWT. Je le dis simplement pour situer le niveau de SWT. Dans les très grandes lignes, SWT délègue l’affichage de la plus-part des composants à l’OS sous-jacent alors que Swing prend en charge la création de l’image des composants puis demande à l’OS l’affichage de ce dessin. Conséquence de cela:

  • Avec Swing le rendu de l’application est le même sur tous les OS alors qu’avec SWT par définition on dépend directement de l’OS,
  • En opposition avec le point précédent, avec SWT le look and feel de l’application ne risque pas de pertuber l’utilisateur. En d’autres termes, si vous lancer Eclipse sous windows vous avez l’impression de travailler sur une application windows classique et non sur une application ‘java’. Exemple encore plus concrêt : si vous travaillez sous XP et que vous utilisez ClearType pour le lissage des polices d’écran, votre application SWT en profite mais pas votre application Swing,
  • Y’a pas photo sur les perfs, cf eclipse vs jBuilder et Netbeans. A nuancer cependant : cette argumentation semble indiscutable uniquement sur plateforme windows,
  • Avec SWT il faut embarquer un dll (ne bouger pas, faut que j’aille au petit coin),
  • Avec SWT on peut intégrer sous windows des composants OLE

Tant que je m’intéressais de loin au problème je me disais que SWT était une initiative plutôt sympathique qui allait pousser Sun à améliorer les performances de Swing et l’intégration des applis Swing au sein de windows au travers par exemple de projet comme JDesktop Integration Components (JDIC) . Mais Swing restait dans mon esprit de facto le standard pour la création de GUI en Java.

Maintenant qu’il faut que je fasse un choix pour un projet précis, le doute m’habite (désolé!).

5 Responses to “Présentation audio/slide de SWT vs Swing”

  1. Franck Says:

    Concernant le rendu des applications Swing, le JDK 1.4 améliore quand même bien les choses, notamment grâce à:
    UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
    Par exemple voici le look de VeloGUI avec cette instruction.
    On a bien le look XP avec une appli pure Swing !

  2. Eric Says:

    Hummm….

    Bon tout d’abord ma première impression sur SWT c’est qu’enfin on quittait le fameux violet des JDK 1.2 et 1.3 pour quelque chose de joli et moderne. Et puis vint les JDK 1.4 et 5.0 et surtout le 1.4.2 et les nettes améliorations de performances avec ces jdk ont vraiment gommé une partie de ce retard (et l’utilisation du l&f de jgoodies rend l’apparence vraiment jolie)

    Sur le problème de performances il n’y a pas tant de gain que ça avec des machines assez récentes et des programmes qui se servent correctement de Swing (jette un coup d’oeil sur IDEA, à défaut d’utiliser Netbeans 4.0 ;-p) et MEME sous l’environnement Windows (j’ai testé chez moi sous Windows -argh-, Eclipse 3, Netbeans et IDEA) mais à condition d’utiliser au moins un JDK 1.4.2.

    Lorsque l’on arrive à un environnement hors Windows, les performances de SWT sont vraiment lamentables ! La seule utilisation potable d’Eclipse sous Linux c’est avec SWT-Fox (http://swtfox.sourceforge.net/) mais comme SWT évolue en fonction des besoins d’Eclipse (et pas forcément au besoin de mr tout le monde) le portage de SWT sous Fox met du temps et visiblement il n’y pas beaucoup de support sur ce projet et cela rajoute 2 couches.

    Bref, SWT semble bien au premier abord quand on utilise Windows avec un JDK 1.3 (qui disparait déjà au profit du 1.4 du côté client), mais après les limitations et les mauvaises performances sur les autres OS sont vraiment bloquantes.

    Et puis quand tu as développé ton appli java en swt avec ton composant OLE, comment tu le fais marcher sous Linux ?

    Bref au fi

  3. Eric Says:

    Oups suite du commentaire…

    Bref au final, l’initiative est intéressante mais à moins de l’intégrer au JDK, j’éviterais de l’utiliser… Mais c’est vrai qu’en choisissant le nom d’Eclipse, les équipes d’IBM ne cherchait pas vraiment à se rapprocher de Sun…

  4. Alexis MP Says:

    Salut Freddy,

    SWT est un effet de bord d’Eclipse qui avait besoin en 2001 de corriger des problèmes de Swing résolus pour la plupart depuis:
    - perf (cf. autres réponses)
    - look-and-feel (cf. autres réponses)
    - facilité de dev: SWT apparait comme simple parcequ’il s’agit d’AWT qui était simple mais limité, d’ou l’arrivée de Swing pour lequel IBM été un moteur principal… ;-)
    JDNC (http://jdnc.dev.java.net) cousin de JDIC, est une initiative intéressante pour répondre à ce pb de “productivité” de dev. La roadmap s’étend sur 2005.

    a+,
    -Alexis qui l’impression que le haut de la vague est passé pour SWT.

  5. Ben Galbraith Says:

    I’m actually not pro-SWT; I’m clearing that up in my next JavaLobby presentation, which is on Swing and will be posted shortly. But, you’re not the only one to think I was an SWT groupie. SWT has some great advantages over Swing, but at the end of the day, I think a light-weight toolkit meets more people’s needs and Swing is a great light-weight toolkit.

Leave a Reply

You must be logged in to post a comment.