Standard Widget Toolkit

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索
Standard Widget Toolkit
開発元 Eclipse Foundation
最新版 3.5.2 / 2010年2月26日
対応OS クロスプラットフォーム
対応言語 Multilingual
ライセンス Eclipse Public License
公式サイト SWT: The Standard Widget Toolkit
テンプレートを表示

Standard Widget ToolkitSWT)は、Javaプラットフォームウィジェット・ツールキットの一種。元々、IBMが開発したが、現在は Eclipse FoundationEclipse IDE と共に管理保守している。サン・マイクロシステムズが Java 標準の一環として提供するJava用GUIツールキットである AWTSwing を代替するものとして開発された。

SWT は Java で書かれている。GUI部品を表示するため、SWT はそのオペレーティングシステムが提供するGUIライブラリを JNI(Java Native Interface)経由で使用する(これはシステム固有のAPIを使う一般的手法である)。SWT を使うプログラムは移植性があるが、ツールキット自体の実装は Java でかかれているにも関わらず、各プラットフォーム固有である。

SWT は Eclipse Public License でライセンスされている。このライセンスは Open Source Initiativeオープンソースライセンスとして認めている[1]

Java GUIツールキットの歴史[編集]

最初のJava用GUIツールキットは、AWT(Abstract Window Toolkit)であり、サンのJava標準の一部として JDK 1.0 で登場した。AWT は比較的単純であり、オペレーティングシステムが提供するネイティブなオブジェクトをJavaコードで包み、メニューやボタンといったGUI部品を生成する。AWTはネイティブウィジェットラッパーとしては非常に薄く、プラットフォーム固有のコードが開発者に透けて見え、バグやOS固有の癖がそのままさらけ出されているため、異なるプラットフォーム間で移植性のあるアプリケーションを作成するには限界があった。

Swingは第二世代のツールキットで、サンが J2SE 1.2 で導入した。AWT よりもオブジェクト指向的である。SwingのGUI部品は 100% Java であり、ネイティブコードは使っていない。ネイティブAPIをラップする代わりに、Swingは低レベルなOSルーチンを使ってGUI部品を自前で描画する。

そのころ、IBMSmalltalkを使った統合開発環境 (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]。このため、SWT が Swing に比べて機能が少ないと批判する人もいる[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より効率がよいことが示されている。しかし、ベンチマークに使われたアプリケーションはそれほど複雑ではなく、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]。このような密な統合の利点を生かした例として、SWTは Microsoft WindowsActiveXオブジェクトもラップ可能である。

拡張性と他の Java コードとの比較[編集]

ネイティブコードを利用するため、SWTクラスでは全ウィジェットクラスについて、継承は容易には許されない。このため、拡張性に問題があるとする人もいる[6]。この点ではSwingの方が容易にカスタマイズ可能である。どちらのツールキットも新たなウィジェットをJavaコードだけを使って書くことができる。

SWTはAWT同様、手動でオブジェクトの解放をする必要がある。SwingやJavaのメモリの自動ガベージコレクションとは異なる。close() しないといけないI/Oリソースと同じである。SWTオブジェクトは "dispose()" メソッドを使って明示的に解放する必要があり、C言語の "free" に似ている[7]。これをしないと、メモリリークなどの好ましくない結果を生じる。ただし、親子関係にある Widget は親を dispose() すれば、子も dispose() される。この問題について、「リソースの明示的解放の必要性は、少なくとも平均的なJava開発者にとっては、開発時間とコストに悪影響を及ぼす」とのコメントもある。さらに「これはありがた迷惑である。Swingがより自動化され遅いのに対して、SWTはよりきめ細かいコントロールができるが複雑になる」としている[6]。SWTが手動でのオブジェクト解放を必要とするのは、ネイティブオブジェクトを使っているのが主な原因である。つまり、それらオブジェクトは Java VM の管理範囲外にあり、Java VM からそれらが解放可能かどうかを判断できない。

プラットフォームサポート[編集]

GTK+ 環境での Azureus BitTorrent クライアント

SWTはプラットフォーム固有のGUIライブラリへのラッパーであるため、Javaが動作するプラットフォーム全てで動作するとは限らない。つまり、SWTはGUIライブラリ毎に移植が必要であり、Javaが新たなプラットフォームに移植されても、即座にSWTが移植されるとは限らない(Swing や AWT はJava本体の一部だが、SWTはそうではない)。また、Windows 上のSWT以外は、比較的効率が悪いと言われている[3]。SWTはプラットフォーム毎に異なるネイティブライブラリを使っているため、プラットフォーム固有のバグもSWTではそのまま存在している。

SWTはSwingよりも低レベルな詳細を開発者に提示する。これはSWTがネイティブライブラリで提供されるGUI機能の上の層であるためであり、ネイティブGUIコードを開発者に提示するのも意図的と思われる。SWTの目的は、高度なユーザインタフェース設計フレームワークを提供することではなく、可能な限り多数のプラットフォームで薄いユーザインタフェースAPIを提供し、その上に高度なGUIアプリケーションを構築できるだけの機能を提供することである。

SWTの実装はプラットフォーム毎に異なるので、複数のプラットフォーム対応としてアプリケーションを配布する際には、プラットフォーム毎のSWT(JARファイル)が必要になる。

SWTはJavaクラスライブラリを必要最小限しか使っていないため、古いJDK(例えば 1.1.8)でも動作するし、Javaクラスライブラリを完全実装していない携帯機器でも動作すると言われている[要出典]

2006年3月現在、SWTがサポートされているプラットフォーム/GUIライブラリは次の通りである。

SWTアプリケーション[編集]

SWTを利用しているアプリケーションとして、以下のものがある。

SWT関係文書[編集]

GUIツールキットとしてはSwingよりも新しいため、SWT関連の文書/書籍はSwingに比べて少ない[要出典]

SWT: The Standard Widget Toolkit は、Eclipse Foundation 推薦のSWT解説書である[8]。他にもSWT関連書籍として以下のものがある。

  • 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. 

ウェブ上でのSWT[編集]

Eclipseコミュニティでの最近[いつ?]の動きとして、SWT(とJFace)をウェブ向けのウィジェットツールキットとして移植しようとしている。Eclipse RAP [9] (Rich Ajax Platform) は Qooxdoo AJAX ライブラリと SWT API を組み合わせたものである。他の Java AJAX プロジェクト(Echo2 や 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]

脚注[編集]

  1. ^ Open Source Initiative. “Licenses By Name”. 2007年3月24日閲覧。
  2. ^ a b Ella Morton. “James Gosling Q & A”. 2007年3月24日閲覧。
  3. ^ a b Performance Benchmarks of Nine Languages”. 2007年3月24日閲覧。
  4. ^ Akan, Ozgur (2004年11月19日). “Why I choose SWT against Swing”. 2006年11月7日閲覧。
  5. ^ Swing vs. SWT Performance - Have a Look at the Call Stacks Javalobby、StephenStrenn、2006年3月3日
  6. ^ a b c Marinilli, Mauro. “Swing and SWT: A Tale of Two Java GUI Libraries”. 2006年11月7日閲覧。
  7. ^ The Java developers guide to Eclipse, 2nd ed., p359
  8. ^ Steve Northover, Mike Wilson. SWT: The Standard Widget Toolkit. Addison-Wesley. 
  9. ^ Rich Ajax Platform (RAP)
  10. ^ SwingWT
  11. ^ swtswing

外部リンク[編集]