:: Comparatif SWT/Swing ::

:: Introduction ::

Il existe à l'heure actuelle deux solutions majeures d'API graphiques en Java: Swing et SWT.
Swing est une bibliothèque graphique multi-plateformes décrivant des composants graphiques complexes, complètement écrits en langage Java, et ne faisant pas appel aux composants de la plateforme, ce qui le rend totalement indépendant du système d'exploitation.
Par opposition, la stratégie de SWT repose sur l'utilisation des composants natifs de l'OS. SWT est malgré tout écrit à 100% en Java : les appels natifs servent uniquement à invoquer les composants de l'OS (mapping "one-to-one"). En conséquence, l'implémentation de l'API SWT n'est pas multiplateforme mais l'application qui l'utilise l'est.
Ce comparatif a pour objectif de donner des éléments de comparaison en faveur ou en défaveur de chacune des solutions pour aider les développeurs à choisir l'une d'entre elles. Les différents aspects abordés sont: les performances, la portabilité, l'apparence, l'utilisation.

:: Performances ::

Au premier abord, il est tentant de penser que la stratégie d'utilisation de composants natifs de SWT est plus performante que celle de Swing.

Pourtant, dans le cas particulier de l'affichage d'un très grand nombre de données, la stratégie de SWT est handicapante. En effet, en SWT les données à afficher doivent systématiquement être copiées dans les composants natifs, alors qu'en Swing elles sont utilisées directement, sans recopie. De plus, l'aspect générique des mécanismes implémentés dans les viewers JFace jouent en défaveur de l'optimisation des performances. Pour s'en persuader, il suffit simplement de créer un TableViewer JFace ainsi qu'une JTable Swing affichant tous deux quelques milliers d'éléments, puis de comparer les temps de chargement.

Cependant, le plus souvent, le nombre d'éléments à afficher dans un composant graphique est modéré. Les données sont souvent filtrées ou rangées dans des structures arborescentes pour rester facilement accessible à l'utilisateur. Dans ces conditions, SWT ne subit pas de pertes de performances significative.

De plus, sur une configuration matérielle moyenne, les composants natifs utilisés par SWT sont plus rapides que les composants complexes de Swing. Ceci se traduit par une meilleure rapidité de chargement des composants et surtout une meilleure réactivité aux sollicitations de l'utilisateur.

 

:: Portabilité ::

La stratégie de SWT oblige l'utilisation de bibliothèques natives spécifiques à l'OS alors qu'il n'y a aucune contrainte particulière en Swing. Quelle que soit l'API, l'application est portable, mais dans le cas de SWT, il faudra préalablement installer les bibliothèques natives et les jars nécessaires sur le système du client ou mettre en place un système de chargement dynamique de ceux-ci.

:: Apparence ::

Swing a l'avantage de permettre facilement le changement et la redéfinition totale de son style par le biais des "Look'n'Feel". Ce mécanisme n'est pas possible en SWT. Les composants natifs utilisés par SWT présentent l'avantage de ne pas dérouter l'utilisateur.

Beaucoup de personnes trouvent les Look'n'Feel fournis en standard avec Swing esthétiquement moins "professionnels" que les composants natifs de Windows et ceux de GTK pour linux utilisés par SWT. Cependant, il est tout à fait envisageable de développer ou d'utiliser un autre Look'n'Feel avec Swing.

:: Utilisation ::

SWT utilisant les ressources de l'OS, le développeur a la charge de les libérer. Sur ce point, Swing est plus simple d'utilisation puisque l'allocation et la libération des ressources sont gérées automatiquement avec le garbage collector.

Cependant, l'utilisation de SWT à l'aide d'une surcouche outil "JFace" s'avère très simple et efficace. Les Viewers JFace permettent d'utiliser les principaux composants non-triviaux SWT par le biais de 3 notions principales qui séparent clairement les responsabilités:
– l'objet Input représente l'objet à afficher par le Viewer
– l'interface ContentProvider est chargée de récupérer les informations sur le contenu de l'objet Input
– l'interface LabelProvider est chargée de produire le contenu graphique à afficher par le Viewer

D'après mon expérience personnelle, le développement d'interfaces graphiques avec SWT/JFace semble plus simple, plus rapide et plus clair qu'en Swing.
De plus, SWT procure un certain nombre de composants réutilisables tels qu'un "assistant" très appréciable dans le domaine professionnel.

De par son ancienneté, l'API Swing est plus documentée que SWT, même si un gros effort a été fourni par IBM à ce sujet.

:: Choix ::

Le choix d'une de ces deux API reste assez difficile car chacune d'elle présente des avantages importants par rapport à l'autre. Il doit être orienté en fonction des besoins de l'application à développer.

Si le nombre de données à afficher est important, SWT est à proscrire. Dans le cas contraire, SWT reste globalement plus performant que Swing. Sa rapidité d'exécution rend les composants graphiques plus réactifs qu'en Swing et procure donc un meilleur confort d'utilisation.

Esthétiquement, Swing est plus personnalisable qu'en SWT. Ce dernier présente l'avantage de ne pas dérouter l'utilisateur en utilisant les composants natifs du système d'exploitation.

J'ai trouvé que la simplicité d'utilisation de JFace ainsi que la disponibilité de composants réutilisables permettent de développer des interfaces utilisateurs assez rapidement.

La nécessité d'utilisation de bibliothèques natives en SWT est incontestablement moins pratique qu'une application Swing sous forme d'un unique jar, déployable facilement et sur n'importe quelle plateforme.

Enfin, on peut souligner qu'à l'heure actuelle, il est plus difficile de trouver des développeurs SWT que des développeurs Swing. De ce fait, le choix de SWT nécessitera souvent une formation des développeurs, même si l'API est assez simple à utiliser.

 

:: Références ::

– SWT: The Standard Widget Toolkit - PART 1: Implementation Strategy for Java™ Natives
– SWT: The Standard Widget Toolkit - PART 2: Managing Operating System Resources
– Aide d'eclipse: Platform Plug-in Developer Guide > Programmer's Guide > JFace UI framework
– Using the Eclipse GUI outside the Eclipse Workbench, Part 1: Using JFace and SWT in stand-alone mode
– Java HotSpot Technology
– Comparing SWT and Swing