 |
Sommaire
|
|
 Introduction |
|
|
|
|
|
|
|
|
Les développeurs Eclipse ont donc conçu SWT (pour Standard Widget Toolkit) comme une alternative à AWT et Swing, considérés comme trop lents pour une application Java qui requiert des performances optimales - ce qui n'a pas empêché d'autres applications équivalentes, comme JBuilder ou NetBeans, de fonctionner sans problème...
Si Swing reste écrit en Java, il diffère de ses successeurs par son utilisation quasi systématique de méthodes graphiques du système d'exploitation pour dessiner et animer ses fenêtres, n'ayant recours à des extensions internes qu'en cas de nécessité. C'était déjà le cas pour AWT, qui dispose d'une bibliothèque native en C (awt.dll), mais les composants modernes de Swing s'affichent par le biais des méthodes de dessin de AWT, donc sans passer par le système, d'où une perte de performance.
Les améliorations de Java 5 ont nettement mis à plat ce problème de performance dans Swing, mais SWT continue d'offrir des différences intéressantes, tout en offrant les performances optimales fournies par sa bibliothèque native swt.dll. awt.dll et swt.dll passent toutes les deux par l'interface native de Java (JNI, Java Native Interface). En ce sens, SWT est plus proche d'AWT que de Swing : ils permettent à Java d'afficher des interfaces riches, sur n'importe quelle plate-forme.
 |
|
Une fenêtre avec SWT
|
SWT a eu pour effet de motiver les développeurs Swing à revoir leur copie en profondeur, ce qui aboutit aujourd'hui à deux bibliothèques graphiques aux performances globalement équivalentes - ce qui n'était pas le cas lors de la création de SWT. Swing conserve l'avantage, car il est installé par défaut avec la machine virtuelle Java, au sein du Java Runtine Environment (JRE), mais l'architecture de SWT fait qu'une interface graphique s'affichera correctement sur n'importe quel
système, tandis que Swing,
 |
|
La même fenêtre
avec l'interface Swing
par défaut
|
avec son système d'émulation de l'interface système, rencontre des problèmes de "look & feel" singulier, notoirement avec l'arrivée de Windows XP, où Swing affichait les composants sous leur forme Windows 200/NT. Si ce dernier problème est réglé, reste que Swing implique de devoir définir l'émulation de l'ensemble des composants graphiques, là où SWT exploite directement le système, ce qui se montre utile pour par exemple dans le monde du développement mobile.
En définitive, le choix entre SWT et Swing/AWT est devenu aujourd'hui une question politique avant tout, voire religieuse. Swing est le standard de fait, et sera toujours maintenu et reconnu par toutes les distributions Java, tandis que SWT a des alliés puissants, à commencer pour Eclipse et son géniteur IBM. La différence, cependant, se fait sans doute avec JFace... |
