Standard Widget Toolkit （SWT ）は、Javaプラットフォーム 用ウィジェット・ツールキット の一種。元々、IBM が開発したが、現在はEclipse Foundation がEclipse と共に管理保守している。サン・マイクロシステムズ がJava 標準の一環として提供するJava用GUI ツールキットであるAWT とSwing を代替するものとして開発された。
SWTはJavaで書かれている。GUI部品を表示するため、SWTはそのオペレーティングシステム (OS) が提供するGUIライブラリ を JNI (Java Native Interface ) 経由で使用する（これはシステム固有のAPI を使う一般的手法である）。SWTを使うプログラム は移植性があるが、ツールキット自体の実装はJavaでかかれているにもかかわらず、各プラットフォーム固有である。
SWTはEclipse Public License でライセンスされている。このライセンスはOpen Source Initiative がオープンソース ライセンスとして認めている[ 1]
最初のJava用GUIツールキットは、AWT (Abstract Window Toolkit ) であり、サンのJava標準の一部としてJDK 1.0 で登場した。AWTは比較的単純であり、OSが提供するネイティブなオブジェクト をJavaコードで包み、メニューやボタンといったGUI部品を生成する。AWTはネイティブウィジェット ラッパーとしては非常に薄く、プラットフォーム固有のコードが開発者に透けて見え、バグやOS固有の癖がそのままさらけ出されているため、異なるプラットフォーム間で移植性のあるアプリケーションを作成するには限界があった。
Swing は第二世代のツールキットで、サンがJ2SE 1.2で導入した。AWT よりもオブジェクト指向 的である。SwingのGUI部品は 100% Java であり、ネイティブコードは使っていない。ネイティブAPIをラップする代わりに、Swingは低レベルなOSルーチンを使ってGUI部品を自前で描画する。
そのころ、IBM はSmalltalk を使った統合開発環境 (IDE) であるVisualAge を開発していた。これをオープンソースとして公開することに決め、それがEclipseの開発へと繋がっていった。EclipseはMicrosoft Visual Studio のようなIDEとも競合できるものとすることを目的としていた。EclipseはJavaで書かれており、IBMの開発者らは「ネイティブのルック・アンド・フィール 」と「ネイティブの性能」を持ったツールキットが必要と考え、Swingを置換するものとしてSWTを開発した。
SWTは、GTK オブジェクトやMotif オブジェクトなど、ネイティブのコードオブジェクトのラッパーである。そのため、SWTウィジェットは「重い」ネイティブオブジェクトに軽いJavaラッパーをかぶせたようなイメージで「重い」と言われることが多い。SWTが必要とする機能をネイティブのGUIライブラリ が持っていない場合、SWTはSwingのように独自のGUIコードをJavaで実装している。SWTは本質的には、AWTの性能やルック・アンド・フィールとSwingのそれとの中間にあると言える。
Eclipse Foundationによれば、SWTとSwingは目標の異なる異なったツールである。SWTの目的は、各種プラットフォームのネイティブウィジェットにアクセスできる共通APIを提供することである。設計目標の第一は高性能なネイティブのルック・アンド・フィールとプラットフォーム統合の達成である。一方Swingは高度にカスタマイズ可能で全プラットフォームに共通なルック・アンド・フィールの提供にある。
SWTはSwingに比較すると単純なツールキットであり、標準的な開発に無関係の機能はあまり存在しない[ 2] [ 3]
Javaの設計者であるジェームズ・ゴスリン は、SWTが単純すぎ、AWTと同じ理由で新たなプラットフォームへの移植が難しいと主張した。単純すぎ、低レベルすぎ、Win32 GUI APIと結びつきすぎているため、Motif やOS X Carbonといった他のGUIツールキットへの対応が難しいとした[ 2]
developer.comにてMauro Marinilliaは「SWTはSwingに比較すると単純すぎるように見える。Swingは多くの洗練された機能を持っているから（例えば、精巧なSwingクラス階層、交換可能なルック・アンド・フィール、Model View Controller 手法など）」と主張した。これに対して、Model View Controllerのような複雑な問題に一種の強制的な正しい手法を適用することは良いことだと思う人もいるだろう。Marinilliaはさらに「（SWTと比較して）Swingの提供する機能は豊富で洗練されており、抽象化レベルが高い（そのため、特製のGUI部品で複雑なGUIを構築するのが容易である）」と続け、「一般にSWTはとっつきやすいが、複雑なGUIをそれで構築しようとすると、Swingの方がより柔軟で容易な結果を生む」とした[要出典 。
SWTは Swing その他の高レベルなGUIツールキットが提供する Model View Controller アーキテクチャを実装していないが、Eclipse プロジェクトの1つとして開発された JFace ライブラリがプラットフォームに依存しない高度な Model View Controller をSWT上に実装している。開発者は、ツリー/テーブル/リストのような複雑なSWTコントロールについて、JFaceが提供する柔軟な抽象データモデルを使うこともできるし、SWTのコントロールを直接使うこともできる。
SWTは「高性能」GUIツールキットとして、Swingよりもシステムリソースを浪費しないよう設計された[ 4] ベンチマーク 比較がいくつか行われ、SWTがSwingより効率がよいことが示されている。しかし、ベンチマークに使われたアプリケーションはそれほど複雑ではなく、SWTが常にSwingより性能が良いとは言えない[ 5]
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はよい選択だ」としている[ 6] Microsoft Windows のActiveX オブジェクトもラップ可能である。
ネイティブコードを利用するため、SWTクラスでは全ウィジェットクラスについて、継承は容易には許されない。このため、拡張性に問題があるとする人もいる[ 6]
SWTはAWT同様、手動でオブジェクトの解放をする必要がある。SwingやJavaのメモリ の自動ガベージコレクション とは異なる。close() しないといけないI/Oリソースと同じである。SWTオブジェクトは "dispose()" メソッドを使って明示的に解放する必要があり、C言語 の "free" に似ている[ 7] メモリリーク などの好ましくない結果を生じる。ただし、親子関係にある Widget は親を dispose() すれば、子も dispose() される。この問題について、「リソースの明示的解放の必要性は、少なくとも平均的なJava開発者にとっては、開発時間とコストに悪影響を及ぼす」とのコメントもある。さらに「これはありがた迷惑である。Swingがより自動化され遅いのに対して、SWTはよりきめ細かいコントロールができるが複雑になる」としている[ 6]
GTK+ 環境での Azureus BitTorrent クライアントSWTはプラットフォーム固有のGUIライブラリへのラッパーであるため、Javaが動作するプラットフォーム全てで動作するとは限らない。つまり、SWTはGUIライブラリ毎に移植が必要であり、Javaが新たなプラットフォームに移植されても、即座にSWTが移植されるとは限らない（Swing や AWT はJava本体の一部だが、SWTはそうではない）。また、Windows 上のSWT以外は、比較的効率が悪いと言われている[ 3]
SWTはSwingよりも低レベルな詳細を開発者に提示する。これはSWTがネイティブライブラリで提供されるGUI機能の上の層であるためであり、ネイティブGUIコードを開発者に提示するのも意図的と思われる。SWTの目的は、高度なユーザインタフェース設計フレームワークを提供することではなく、可能な限り多数のプラットフォームで薄いユーザインタフェースAPIを提供し、その上に高度なGUIアプリケーションを構築できるだけの機能を提供することである。
SWTの実装はプラットフォーム毎に異なるので、複数のプラットフォーム対応としてアプリケーションを配布する際には、プラットフォーム毎のSWT（JARファイル）が必要になる。
SWTはJavaクラスライブラリ を必要最小限しか使っていないため、古いJDK（例えば 1.1.8）でも動作するし、Javaクラスライブラリを完全実装していない携帯機器でも動作すると言われている[要出典 。
2006年3月現在、SWTがサポートされているプラットフォーム/GUIライブラリは次の通りである。
SWTを利用しているアプリケーションとして、以下のものがある。
GUIツールキットとしてはSwingよりも新しいため、SWT関連の文書/書籍はSwingに比べて少ない[要出典 。
SWT: The Standard Widget Toolkit は、Eclipse Foundation推薦のSWT解説書である[ 8]
Rob Warner, Robert Harris (2004年). The definitive guide to SWT and JFace . Apress Eric Clayberg and Dan Rubel (2004年). Eclipse: Building commercial-quality plug-in . Addison-Wesley Erich Gamma and Kent Beck (2004年). Contributing to Eclipse . Addison-Wesley Sherry Shavor et al (2004年). The Java Developers Guide to Eclipse . Addison-Wesley
Eclipseコミュニティでの最近 [いつ? の動きとして、SWT（とJFace）をウェブ向けのウィジェットツールキットとして移植しようとしている。Eclipse RAP [ 9] GWT ）と同様、SWT APIを使うことで、デスクトップと同じ形でWeb用のアプリケーション開発が可能となる。
Eclipseが人気を得てきた結果として、SwingとSWTをある意味で「統合」しようとする活動もある。
SwingとSWTの統合については、以下のようにいくつかの異なる手法が存在している。
Eclipseプロジェクトでは、SwingウィジェットをSWTコンテナウィジェットに埋め込もうとしている[要出典 。
SwingWT はSwing APIの代替実装を提供しようとするプロジェクトである。その1つとしてSWT上でSwingウィジェットを使えるようにするプロジェクトが行われている[ 10] SWTSwing は、逆に Swing 上で SWT API を提供するプロジェクトである。これによりSWTがサポートされていないプラットフォーム上でもJavaさえ動作すればSWTアプリケーションを実行可能となる[ 11]
