La première des questions qui se posent lorsqu’on veut développer des RDA1) en Java porte sur le choix entre SWT et Swing.

Le débat dure maintenant depuis plusieurs années :

1. Swing, apparu en premier, est le standard de Java.
2. Malgré sa richesse, les premières lacunes de Swing lui valent une réputation médiocre et l’engouement pour le web retarde des améliorations sans doute jugées moins urgentes que le développement de J2EE.
3. SWT apparaît alors pour éclipser Swing en apportant une réponse différente et surtout plus pragmatique.
4. Swing a fait des progrès, certes tardifs mais suffisamment significatifs pour redorer son blason.

Bref, la scission perdure et le choix apparaît plus difficile aujourd’hui, comme l’illustrent ces réflexions d'un "ex-amateur" de SWT.

Pour ma part, je partage le doute exprimé :

• Swing est très probablement l’API la plus puissante sur ce domaine. Vous savez qu’en l’adoptant, vous rencontrerez peu de limites.
• En contrepartie, Swing n’est pas facile à maîtriser et réclame donc des développeurs d’un certain niveau.
• SWT séduit par son efficacité, brillamment démontrée par Eclipse.
• Le look&feel de SWT, plus proche de celui de l’OS, attire aujourd’hui plus que celui de Swing malgré les possibilités de personnalisation de ce dernier. Mais Swing progresse sur le sujet. Remarquons aussi au passage que l’aspect de la plate-forme Eclipse n’est pas standard (remarque à destination de ceux qui choisiraient Eclipse RCP en pensant s’intégrer au look de l’OS). Si on veut respecter le look de l’OS de façon stricte, il faut donc se contenter de SWT seul (ou AWT).
• L’API SWT est plus simple à maîtriser mais c’est surtout parce qu’elle est plus limitée. Dès que l’on souhaite aller un peu plus loin que ce qu’elle propose en standard, la complexité apparaît inévitablement.
• Les limitations de SWT peuvent s’avérer assez sévères. Pour s’en persuader, il suffit de comparer les possibilités (et les limites) du composant Table avec celles de JTable.
• Swing offre plus de souplesse pour la création de composants personnalisés.
• Les différences de performance ne sont plus vraiment d’actualité car Swing a beaucoup progressé sur ce point. Notons par ailleurs que SWT n’est pas forcément la panacée sur d’autres OS que Windows.
• L’aspect “multi-plateforme” me semble secondaire dans la mesure où ce besoin n’est pas si courant qu’on veut bien le dire. Mais si celui-ci est important, les deux bibliothèques sauront le prendre en compte, bien que Swing présente ici un certain avantage.
• SWT intéragit plus facilement avec l’OS, notamment grâce à la possibilité d’intégrer des ActiveX sous Windows. Du côté de Swing, les réponses à ce besoin commencent seulement à émerger (JDIC).
• En réalité, il n’y a pas de différence fondamentale sur la manière de développer (dans les deux cas, c’est de la programmation événementielle en Java avec des composants graphiques à positionner selon des layouts). On peut considérer que les deux API sont de “bas niveau”, simplement parce qu’elles sont difficilement accessibles à des développeurs fonctionnels. Il apparaît donc nécessaire de disposer d’une sur-couche de composants évolués pour améliorer la simplicité et la productivité des développements et ce constat vaut autant pour Swing que pour SWT.
• Quoi qu’il en soit, ce sont deux bibliothèques de qualité qui permettent de répondre aux besoins en IHM de manière efficace du point de vue ergonomique.

D’autres commentaires sur ce débat :

SWT - So What?
Why don't you ship Swing apps?
Swing vs SWT... again!
Why I choose SWT against Swing
SWT and Swing: Clash of philosophies
Swing & SWT - Some Thoughts
Comparatif SWT/Swing
Swing has failed. What can we do?

A voir aussi : ce compte-rendu sur les dernières évolutions de Swing.