SWT (Standard Widget Toolkit) est un toolkit destiné aux développeurs Java qui fournit une API transférable et une intégration étroite à la plate-forme de l'interface graphique du système d'exploitation natif sous-jacent.
De nombreuses tâches de programmation de bas niveau de l'interface utilisateur sont traitées dans des couches supérieures de la plate-forme Eclipse. Par exemple, la marque plugin.xml pour les contributions de l'interface utilisateur indique le contenu des menus et barres d'outils sans recourir à la programmation SWT. Par ailleurs, les afficheurs et actions JFace offrent des implémentations pour les interactions courantes entre applications et widgets. Cependant, la connaissance de l'architecture et de la philosophie de conception SWT sous-jacente est importante pour comprendre comment le reste de la plate-forme fonctionne.
Une question courante concernant la conception d'un toolkit de widgets est la tension qui existe entre les toolkits transférables et l'intégration de la plate-forme. Java AWT (Abstract Window Toolkit) fournit des widgets intégrés à la plate-forme pour d'autres de niveau inférieur, tels que listes, textes ou boutons. En revanche, il n'offre pas l'accès à des composants de niveau supérieur, tels que des arborescences ou du texte enrichi. Les développeurs d'application se retrouvent alors dans une situation de "plus petit dénominateur commun" où ils ne peuvent utiliser que les widgets disponibles sur toutes les plates-formes.
Le module de développement Swing tente de résoudre ce problème en fournissant des implémentations non natives de widgets de niveau supérieur, tels que des arborescences, des tables et du texte. Ceci fournit un grand nombre de fonctionnalités, mais les applications développées en code Swing restent en dehors, du fait qu'elles sont différentes. Les niveaux d'émulation de présentation de la plate-forme permettent aux applications de ressembler bien plus à la plate-forme, mais l'interaction de l'utilisateur est suffisamment différente pour être remarquée. Ceci rend difficile l'utilisation des toolkits émulés pour générer des applications qui soient compétitives avec les applications prêtes à l'emploi, développées spécialement pour la plate-forme d'un système d'exploitation spécifique.
SWT tente de résoudre ce problème en définissant une API transférable commune, fournie sur toutes les plates-formes supportées, et en l'implémentant sur chaque plate-forme, chaque fois que possible à l'aide de widgets natifs. Ceci permet au toolkit de refléter immédiatement les modifications apportées à la présentation de l'interface graphique du système d'exploitation sous-jacent, tout en maintenant un modèle de programmation cohérent sur toutes les plates-formes.
Le problème du "plus petit dénominateur commun" est résolu par SWT de diverses façons :
L'intégration de la plate-forme n'est pas seulement une question d'apparence. Une intégration étroite inclut la capacité d'interagir avec des fonctions du bureau natif, telles que glisser-déposer, l'intégration avec les applications du bureau du système d'exploitation et l'utilisation des composants développés avec les modèles de composant du système d'exploitation, tel que Win32 ActiveX.
Le support d'ActiveX dans SWT est abordé dans l'article ActiveX Support in SWT.
La cohérence est également atteinte dans le code lui-même en fournissant une implémentation qui semble familière au développeur du système d'exploitation natif. Plutôt que de masquer les différences du système d'exploitation dans le code C natif ou de tenter de générer des couches transférables et non transférables dans l'implémentation Java, SWT fournit des implémentations isolées et distinctes en Java pour chaque plate-forme.
L'une des règles d'implémentation importantes est que les natifs en C mappent un sur un les appels au système d'exploitation. Un programmeur Windows reconnaît immédiatement l'implémentation du toolkit SWT sous Windows, car il utilise les natifs qui mappent directement sur les appels système utilisés en C. Rien de la "magie de la plate-forme" n'est masqué en code C. Un développeur de plate-forme peut voir le code et savoir exactement quels appels de la plate-forme sont exécutés par le toolkit. Ceci simplifie considérablement les opérations de débogage. En cas d'incident lors de l'appel d'une méthode native, l'appel de l'API de la plate-forme avec les mêmes paramètres du code C connaîtra le même échec. (Ce point est abordé en détail dans l'article SWT Implementation Strategy for Java Natives.)