Standard Widget Toolkit
SWTは、GTKオブジェクトやMotifオブジェクトなど、ネイティブのコードオブジェクトのラッパーである。そのため、SWTウィジェットは「重い」ネイティブオブジェクトに軽いJavaラッパーをかぶせたようなイメージで「重い」と言われることが多い。SWTが必要とする機能をネイティブのGUIライブラリが持っていない場合、SWTはSwingのように独自のGUIコードをJavaで実装している。SWTは本質的には、AWTの性能やルック・アンド・フィールとSwingのそれとの中間にあると言える。
Eclipse Foundationによれば、SWTとSwingは目標の異なる異なったツールである。SWTの目的は、各種プラットフォームのネイティブウィジェットにアクセスできる共通APIを提供することである。設計目標の第一は高性能なネイティブのルック・アンド・フィールとプラットフォーム統合の達成である。一方Swingは高度にカスタマイズ可能で全プラットフォームに共通なルック・アンド・フィールの提供にある。
SWTはSwingに比較すると単純なツールキットであり、標準的な開発に無関係の機能はあまり存在しない。このため、SWTがSwingに比べて機能が少ないと批判する人もいる。
Javaの設計者であるジェームズ・ゴスリンは、SWTが単純すぎ、AWTと同じ理由で新たなプラットフォームへの移植が難しいと主張した。単純すぎ、低レベルすぎ、Win32 GUI APIと結びつきすぎているため、Motif やOS X Carbonといった他のGUIツールキットへの対応が難しいとした。
SWTウィジェットは、ネイティブウィジェットと同じルック・アンド・フィールを提供する。これとは対照的に、Swingのウィジェットはネイティブウィジェットに近い複製である。場合によっては、この違いが見た目にも明らかとなる。例えば、Mac OS Xのツリーウィジェット機能はツリーの展開時にアニメーションを行い、デフォルトボタンもユーザーがフォーカスした際にアニメーションを行う。Swingでは、これらのアニメーションは行われない。
SWTはネイティブGUIコードの単純なラッパーであるため、(ネイティブAPIが互換を保つ限り)ネイティブコードが変更されても大きな修正を必要としない。OSベンダーはAPI上の互換性を保つよう常に気をつけている。Swingでは事情が異なる。Swing は動作中のアプリケーションのルック・アンド・フィールを交換可能であり、ネイティブGUIのテーマをエミュレート可能である。この機能はOSのGUIが変更されるたびに、その変化(テーマやその他のルック・アンド・フィールの更新)を反映しなければならない。逆に言えば、ネイティブAPIが変更されれば、SWTは修正が必須となるが、Swingは修正の必要がない。
SWT は「プラットフォームとの密な統合」を目指しており、ネイティブウィジェットを利用する。developer.com の Mauro Marinilliaによると「ネイティブプラットフォームとの密な統合が必要なら、SWTはよい選択だ」としている。このような密な統合の利点を生かした例として、SWTは Microsoft Windows のActiveXオブジェクトもラップ可能である。
Eclipseコミュニティでの最近の動きとして、SWT(とJFace)をウェブ向けのウィジェットツールキットとして移植しようとしている。Eclipse RAP (Rich Ajax Platform) はQooxdoo AJAX ライブラリとSWT APIを組み合わせたものである。他のJava AJAX プロジェクト(Echo2やGWT)と同様、SWT APIを使うことで、デスクトップと同じ形でWeb用のアプリケーション開発が可能となる。