ネタは、タイトルにあるとおりに NetBeans に先行搭載された Swing Application Framework です。

今回はバックグランドタスクを使う簡単なアプリケーションを作ってみました。

細かい所は省略して適当に作ってみました（＾＾；

本当に適当です（＾＾;;;

で、どのような物を作って試したかというと以前 SwingWorker を試したときのものと同じようなものです。

実際の動作は Java Web Start を配備しましたので興味のある方はどうぞ。

Launch JSR296 TEST

API ドキュメントが英語なので良く解らないので本当に適当です。

詳しくは下記に悪戦苦闘の様子が綴ってあるので暇な方はご覧ください。

間違っていたり、なんでこんなことしてるの？ってことがあると思いますが

優しく、猿でも解るようなアドバイスは歓迎いたします。

JSR296 on NetBeans バックグラウンドタスクを試す

プロジェクトの設定を下図のようにします。

次にプロジェクトのプロパティを設定します。

GUI ビルダーを使用して下図のようにレイアウトします。

ボタンにアクションを設定します。

jButton1 を右クリックして [ アクションを設定... ] をクリックします。

設定ウィンドウが表示されます。

下図のように設定します。

設定が完了するとコードエディタにジャンプします。

@Action アノテーションのついたメソッドが自動生成されてます。

下記のようにイベント処理を記述します。

アクションイベントを実行するための（リソースファイルを使用して）コードが生成されます。

同じように jButton2 のアクションを設定します。

これでアプリケーションは完成です。

さっそくプロジェクトを実行してみましょう。

ちゃんとうごきました（＾＾）

リソースファイルの Swing_type_newView.properties ファイルを確認します。

ボタンコンポーネントのテキスト、アイコン、ツールチップの情報が自動生成されてます。

非常に便利ですね（＾＾）

@Action アノテーションによってメソッド名をキーにこれらのリソースファイルにアクセスできるわけです。

今更ですがアノテーションによって Java 言語は便利になったと思う。

さて、JSR296 を使用しない普通の Swing アプリケーションのイベント処理コードをもう一度みてみましょう。

さて、どちらがいいでしょうか？

個人的には NetBeans のような強力な GUI ビルダーを搭載している統合開発環境を使うのであれば

どちらでもいいような気がします。

メニューバーやらステータスバー、プログレスバーなどをはじめ、いたれりつくせりなんだけど・・・

じゃあ、JSR296 の魅力って大したことないのだろうか？

もう少し、調べてみたほうがいいようです。

ボタンに使用しているアイコンは NetBeans 日本語コミュニティのマスコットです。

http://ja.netbeans.org/nekobean

作者はカネウチカズコさんです。

http://blog.cgfm.jp/mutsuki/

とても可愛いキャラクターで人気者です。

まず、今までの普通の Swing アプリケーションをつくります。

テキストエリアとボタンが二つだけのシンプルなもので、

[ Plz Click me! ] ボタンが押されたらテキストエリアに文字を追加する。

[ Clear ] ボタンが押されたらテキストエリアをクリアするというものです。

NetBeans の GUI ビルダーを使用して簡単に作成できます。

コードは下記のようになります。(GUI の自動生成部分は折りたたんで非表示になってます）

プロジェクトを実行すると下図のように動きます。

簡単に作成できました。

ボタンに使用しているアイコンは NetBeans 日本語コミュニティのマスコットです。

http://ja.netbeans.org/nekobean

作者はカネウチカズコさんです。

http://blog.cgfm.jp/mutsuki/

とても可愛いキャラクターで人気者です。

さて、これを NetBeans に先行導入された JSR296 を使用してつくったらどうなるのか？

それは、また今度（＾＾； 試してみます。

おそらく簡単にできます。

いや、間違いなく簡単にできます。

今回は NetBeans と言えば GUI 操作で簡単に開発できるというところに焦点を当てて見てみます。

まず、JButton のプロパティを表示させます。

text に Close が設定されてます。

右端の [...] ボタンを押します。

下図のように Close! と変更してみます。

予想通りの結果です。

ボタンのテキストが Close! と変わってます。

リソースファイルの DesktopApplication1AboutBox.properties ファイルを見てみましょう。

ファイルの最後に下記のコードが追加されました。

うーん・・・ ちょっと変。

変更前はこんなの無かった・・・

text プロパティを元に戻し、action を見てみよう。

CloseAboutBox となってます。

また右端の [...] ボタンを押します。

今まで見たことのないものが出てきました。

ヘルプがあるので詳しくはそれを参照してください。

そのヘルプによるとビジュアルコンポーネントのアクションを表すのに使用するテキストを

属性の基本タブ、テキスト欄に記入すればいいらしい。

下図のように Close!! と変更してみた。

おや！ text のプロパティ値が Close!! に変わってる。

こちらも予想通りに Close!! に変わってます。

DesktopApplication1AboutBox.properties ファイルも Close!! に変更されてます。

どうやら action プロパティの設定画面で設定するのがいいようですね。

とりあえず、ざーっと調べてみたので簡単なプログラムを組んで試してみよう。

DesktopApplication1AboutBox クラスの JButton についてみてみます。

まず、どういうふうに JButton を生成しているのか見てみましょう。

そして、アクションの定義は

リソースファイルの DesktopApplication1AboutBox.properties ファイルは

となってます。

アクションの定義が非常にシンプルになってますね。

今までのスウィングアプリケーションとはまるで違います。

下記のコードがこの仕組みの鍵となってます。

javax.swing.ActionMap actionMap = org.jdesktop.application.Application.getInstance(desktopapplication1.DesktopApplication1.class).getContext().getActionMap(DesktopApplication1AboutBox.class, this);

closeButton.setAction(actionMap.get(“closeAboutBox”)); // NOI18N

closeButton.setName(“closeButton”); // NOI18N

javax.swing.ActionMap actionMap を取得してます。

これはこの前の org.jdesktop.application.ResourceMap resourceMap の取得と同じ考え方です。

ApplicationContext インスタンスの参照を取得します。

actionMap には @Action が付いたメソッドがメソッド名をキーとして保持されます。

よって、closeButton.setAction(actionMap.get(“closeAboutBox”));

これで、

@Action public void closeAboutBox() {

    setVisible(false);

}

と関係が結びつく訳ですね。

org.jdesktop.application.ResourceMap か javax.swing.ActionMap actionMap の違いと @Action メソッドの

関連付けが有るか無いかの違いだけのようです。

今日はここまでにして次は GUI 操作でちょこっといじってみたいと思います。

そう、私は気になることは試して壊してしまうタイプなのです。（＞＜）

DesktopApplication1AboutBox クラスを参考にします。

initComponents() メソッドの処理の中に見慣れないコードがあったのを覚えているでしょうか？

まず、JDialog のタイトルを見ましょう。

org.jdesktop.application.ResourceMap resourceMap = org.jdesktop.application.Application.getInstance(desktopapplication1.DesktopApplication1.class).getContext().getResourceMap(DesktopApplication1AboutBox.class);
setTitle(resourceMap.getString(“title”)); // NOI18N
setModal(true);
setName(“aboutBox”); // NOI18N

この見慣れないコードによってリソースファイルの情報を取得してアプリケーションにセットしてます。

最初の３行で org.jdesktop.application.ResourceMap resourceMap にリソースファイルの情報を取り込んでます。

desktopapplication1.DesktopApplication1.class のインスタンス、コンテキストを取得し、

getResourceMap() メソッドの引数で指定されている DesktopApplication1AboutBox.class のリソースファイル

つまり、DesktopApplication1AboutBox.properties ファイルが使用されるということですね。

４行目の

setTitle(resourceMap.getString(“title“)); // NOI18N

によって DesktopApplication1AboutBox.properties の

title = About: ${Application.title} ${Application.version}

でタイトルが設定されるようです。

${Application.title} ${Application.version} この二つはDesktopApplication1.properties の４行目と５行目にある

Application.title = +++ ** Basic Application Example ** +++

Application.version = 1.012345

です。

なんでこんなになっているんでしょうか？

リソースファイルを全てクラスごとに分けてもいいんでしょうが、アプリケーション全体で共有できるものはしたほうがいい。

たぶん、きっとそういう考えからだと思う。

その他のラベルも同じ仕組みになってます。

ソースを見れば一目瞭然です。

この DesktopApplication1AboutBox クラスは NetBeans によって自動生成されたものでしたね。

ちょっとラベルのプロパティを覗いてみましょう。

appTitleLabel を見てみます。

Swing Application Framework のリソースインジェクションを使用するために、

リソースとして定義のチェックボックスにチェックを入れてありますね。

ローカライズ機能を使用するために、ローカライズ版にもチェックが入ってます。

ここで注目なのがスコープの設定がアプリケーションになっているということです。

キーに先ほど出てきた DesktopApplication1.properties ファイルの Application.title が設定されてます。

値はそれに設定した +++ ** Basic Application Example ** +++ が入ってます。

これは自動生成されたものですが、自分で作ったラベルにももちろん設定できます。

こういった設定が GUI 操作でできるのはうれしいです（＾＾）

さすが NetBeans と褒めておこう！

ちなみに？マークのヘルプがあるので表示させてみる。

ここではリソースファイルと言わずにプロパティファイルと言ってますね。

そのプロパティファイルの値をアプリケーションリソースと呼んでます。

そう言われてみればそうなんですが、ここで言うプロパティファイルは一般的にはリソースファイルでも通じますよね？

なんだか細かなことだが気になります。

とりあえず今日は、イベントを発生させることができないラベルについて調べてみました。

面白い仕組みになってます（＾＾）

アプリケーションのプロパティを見てみます。

このように自動生成されてます。

次に

デスクトップアプリケーションを見てみましょう。

説明に共通アプリケーションを補う Swing Application Framework 固有のプロパティとあります。

これも上記のように自動生成されてます。

これらって、何処かで見たような記憶がありますね。

面白いことにこれらの設定は Swing Application Framework のリソースファイルに反映されるようです。

そう、Help メニューのAbout… ポップアップする JDialog の表示内容です。

試しに設定を下記のように変更してみます。

それでは、アプリケーションを実行してみましょう。

おお！ 予想通りの結果ですね。

リソースファイルの DesktopApplication1.properties ファイルも変更されてます。

ここで天の邪鬼な私としては、リソースファイルの DesktopApplication1.properties ファイルを変更したらどうなる？

もちろん、試してみました。

上記のように設定を変更し、アプリケーションを実行してみます。

やはり、想像通りの結果となりました。

プロジェクトのプロパティの設定も確認してみます。

あれれ？

アプリケーションの設定は変更されてないですね。

デスクトップアプリケーションはリソースファイルでの変更が反映されてるのに・・・

まぁ、こういう仕様なんだと思って深く追求しないことにしときます。（追求する力が無いというのが正解）

とりあえず、リソースファイルの情報をなんらかの手段によってアプリケーションに反映させていることだけは確認できました。

今日はここまでってことで（＾＾；

このトリックがどうなってるのか楽しみですね。

ぱっと見は普通の JDialog のようですが・・・

また見慣れないコードがあります。

それに initComponents() の処理のところにこんなのも

いったいこの怪しいコードで何がおこなわれているのでしょうか？

プロジェクトツリーの desktopapplication1.resources の中にある

DesktopApplication1 properties

DesktopApplication1AboutBox properties

DesktopApplication1View properties

この三つのプロパティファイルが JSR296 の鍵になるはずだから

見慣れない怪しいコードはこれらが深く関わっていると思う。

とりあえず、このプロパティファイルをちょっと見てみましょう。

キーとバリューの関係のようですね。

おそらく、JSR296 ではこれらのリソースファイル（プロパティファイル）を積極的に使用するのでしょうか。

適当に変更して変化を見てみるのも面白そうですが今回はここまでにします。

とりあえず、プロジェクトのプロパティの設定もしてないのでそれをしてからいろいろ遊んでみようと思います。

このクラスは DesktopApplication1 クラスの startup() メソッドにある show() メソッドに渡されます。

GUI の初期化などをしています。

継承元の FrameView クラスをみてみます。

java.lang.Object
  → org.jdesktop.application.AbstractBean
      → org.jdesktop.application.View
          → org.jdesktop.application.FrameView

上記のような継承関係になってます。

rameView クラスのドキュメントがないのでとりあえずソースを見てみます。

getFrame()メソッドに何やら怪しい方法で JFrame のタイトルを取得して生成しているようです。

このようなコードは JSR296 を使う上ではよく見ることになるでしょう。

リソースファイルにアクセスして指定したコンポーネントのプロパティを取得し、それらを使用するのが

JSR296 の必須テクノロジーのようです。

とりあえず今は何かな？と思うだけでさらりと流しましょう。

FrameView クラスは JFrame を作るためのクラスのようなものですね。

しかし、FrameView クラスは JFrame クラスを継承せずに View クラスを継承してます。

よって、menu bar, tool bar, component,status bar が View クラスによって作成されます。

これもソースを見れば BorderLayout で配置されているのが確認できます。

あとこの DesktopApplication1View クラスを見ると

helpMenu.setText(resourceMap.getString(“helpMenu.text”)); // NOI18N
helpMenu.setName(“helpMenu”); // NOI18N

とか、

ResourceMap resourceMap = getResourceMap();
int messageTimeout = resourceMap.getInteger(“StatusBar.messageTimeout”);

のような感じのコードとか、

@Action

などがあります。

それ以外のコードは今までと変わりないので問題ないですね。

上記のコードがいったい何なのか楽しみですね（＾＾）

＊注意　この内容は Javadoc を元に調べたもので英語が良く解らない私が勝手に解釈した内容です。

　　　　よって間違っているかもしれません。

getApplication() メソッドです。

メソッド名からただのゲッタのようですね。

DesktopApplication1 クラスのインスタンスを返すだけのようです。

これで自動生成された DesktopApplication1 クラスを一通りみたわけですが今までの Swing アプリケーションとは

ずいぶん違ってきてますね。

次は DesktopApplication1View クラスについてみることにします。

＊注意　この内容は Javadoc を元に調べたもので英語が良く解らない私が勝手に解釈した内容です。

　　　　よって間違っているかもしれません。