trigger on

思ったよりは盛り上がっていないJavaFXだけれども、
とりあえず、手に入るドキュメントは読了。
オーサリングツールが公開されれば盛り上がるかな。

trigger on句はちょっとした革命。
JavaだとBean仕様に従ってアクセサメソッドを定義していたけど、
C#のように｢必要な時だけ定義｣して、
=演算子の代入で自動的にtrigger on句で
指定した処理が起動するようになってる。
つまり、

class Model
{
attribute hoge: Number;
}

trigger on Model.hoge = newValue
{
// 処理1
}

として、

Model{hoge: 10}

とすると、
代入する際には、triggerで指定した処理1が実行される。
いつのためなのか誰の為なのかわからないアクセサメソッドを
必ず書いていたわけで、それに比べると素敵だ。

でもTriggerが凄いのはここから先。
例えば、

　trigger on new Model
{
// 処理2
}

として、

　Model{}

とすると、
なんと処理2が走る。
trigger on句の後に指定されいているnew Model句は
Modelのインスタンス生成のタイミングを指定している。
これはただのアクセサメソッドがどうのこうのと言うよりも、
アスペクトに近いものと判断したほうがよさそうだ。

ただし、そうなるとややこしい。
functionやoperationとしてモデルの関数を明示的に実装するのか、
それともtriggerで暗黙的に実装するのか。
以前にSpring FrameworkのAOPでValueObjectに対して
振舞を持たせている(=ドメイン化)人がいたけれども、
そういった迷路がおぼろげながら僕の眼前にも広がるのかもしれない。

兵士はどこだ？

Java FXだ。

FlexやらApolloやらWPF/Eと戦うための、
僕達に突然与えられた、武器だ。
まだ未完成でも、竹槍よりはましだろう。

兵士はここだ。

君は？

// 久しぶりに更新してみたけど、微妙な投稿です。
// このブログのUIにも飽きたので、
// ただいま鋭意作成中です。乞わないご期待。

Strutsに見るMVC

今更ながら気付いたこと。

ご存知のことかどうかは知らないし、
君が知らなくても僕はここに書くわけだけれども、
Strutsはもう随分長い間、
プレゼンテーション層のフレームワークの長に君臨している。
ご存知のことかどうかは知らないし、
君が知らなくても僕はここに書くわけだけれども、
JSFはもう随分長い間、
｢次に来るのはJSFだ｣と言われて、未だに来ない。
(そして僕の同僚の優秀なエンジニアは｢もう来ない｣と言う)

StrutsのActionFormはMVCで言うところのモデルだ。
PACよりもDocument-ViewよりもMVCが好きな僕だが、
そんなことに今更気付いた(もう何年ですか？)。
そのことにより、Strutsはアーキテクチャパターンとして
実はMVCはそんなに気にしていないことに気付く(正確にはMVCモデル2)。
｢プレゼンテーション層以外を規定しない｣と言われるStrutsだけど、
ビジネス層を呼び出す責務を負うクラスが、
ActionFormではなくActionだという非常に重い規定はしている。
ActionはMVCではコントローラの扱いであり、
｢小さなServlet｣である。
そのActionのメソッドAction#execute(..)は、
ActioFormを引数として呼び出される。
コントローラの引数としてモデルが渡されるのである。
古典的MVC主義者にとっては驚愕の事実である。
さらにStrutsはDynaFormを導入することにより、
｢モデルとしてのActionForm｣を
ただの｢リクエストパラメータを入れるだけの箱｣にまで格下げした。

一方、JSFは比較的綺麗なMVCだ(あくまでも比較的に)。
｢JSFのBackingBeanはStrutsのActionFormみたいなもの｣
と説明する人達がいるが、とんでもない。
BackingBeanはあからさまにモデルオブジェクトだ。
BackingBeanとActionFormが似ているのは、
それがプレゼンテーション層に属していて、
リクエストパラメータを格納するという点だけだ。
属するレイヤが同じでも、演じるMVCの役割は異なる。
JSFはStrtusのようにむやみやたらに自作のモデルクラスを
HttpServletRequest#setAttribute(..)しない。
｢リクエストの場合はActionFormだけど
表示する場合は自作のモデルクラス｣という、
汚いアーキテクチャを避けることができるようだ。

｢だからStrutsがダメだ｣というわけではないし、
何より、未だに仕事でお世話になっている。
｢だからJSFがいい｣というわけではないし、
何より、未だに仕事でお世話になったことがない。

Synthetica

｢Swingは動作速度が非常に遅い｣とか、
｢Swingは見た目が酷い｣とか、
そんな話を今でも持ち出す人達は多い。

さて、Wizardryと女神転生で青春時代を過ごした僕としては、
ゲームを作るなら3Dダンジョンなわけだ。
さらに、DiabloとRogue好きな僕としては、
ゲームを作るならHack&Slashなわけだ。
だけれども、ゲームを最後まで作りきれることはなかなかなく、
ゲーム作成熱が上昇する度に既存コードは陳腐化し、
毎回々々スクラッチ開発になる。
｢それは困るなぁ｣と思い、せめて3Dダンジョンの部分は、
その抽象的なデータを編集するツールを作ろうかと考えた。
そこで、DungeonEditor。



ダンジョンの構成要素である通路、ドア、壁、階段を、
ダンジョンに配置していけるアプリケーション。
｢どのように表示するか｣は、時代と共に陳腐化するけれども、
｢何を表示するか｣は、あまり変わらない。
少なくとも僕が求める3Dダンジョンは、あまり変わらない。
編集したダンジョンはJOGLでプレビューすることができるが、
それは、現状、Javaで3Dダンジョンを
表現する最も優れた手段がJOGLだから採用しているのであって、
もっと優れた手段が提供されれば、そちらを採用することになる。
重要なことは、そうなったとしても、
3Dダンジョンの情報が保存されたファイルは利用できることである。
いわゆるMVCの発想を借用して、
モデルからビューへの依存を最小限に留めている。

まったく前置きが長くなったが、
DungeonEditorはSyntheticaを利用して作成されている。
このSyntheticaは、JDK1.5から提供されたSynthの機能を利用して、
オシャレなLookAndFeelを提供するものだ。
Syntheticaは商用利用は有償だが、
いわゆる｢フリーソフト｣のカテゴリに属するアプリケーションへの適応は、
無償で利用することができる(詳細はここ)。
Windowsのネイティブウィンドウよりも、個人的には美しく感じる。

｢Swingは動作速度が非常に遅い｣とか、
｢Swingは見た目が酷い｣とか、
そんな話を今でも持ち出す人達は多い。
今回は見た目の話を少しだけ。
僕はSwingが好きだから、
世間の誤解が少しでも解けたらな。

Syntheticaで日本語表示

発生因の起源

少し前にJDKのソースコードが公開されたので、
前々から拝見したいと思っていたので早速ダウンロード。

闇雲に見ても仕方がないので、
誰もが叩いたことのある(わけがない)javaコマンドから。
全然知らなかったのだけれど、
JVMもJavaコマンドも、全部JNIに従って書いてるみたいで、
(JNIでtypedefされている変数定義を使ってる)
JNIの経験があると特に躓かずにC言語として読んでいける。
｢メインクラス取得したー！｣とか、
｢メインメソッド取得して叩いたー！｣とか、
今までは想像するしかなかった出来事の原因が、
まさに今、目の前のソースに書かれている！

僕が見たかったソースは、SunGraphics2Dクラス。
java.awt.Graphicsクラスは、
以下のような継承関係にある(ずれてる？)。

　Graphics
　　△
　　｜
　Graphics2D
　　△
　　｜
　SunGraphics2D

Graphics、Graphics2Dは、
これまでのJDK添付のsrc.zipからソースコードを見ることが出来たが、
どれもこれもabstractメソッドばかりで、
どんな風に実装されているのかわからなかった。
しかも、デバッグでSunGraphics2Dが実装していることはわかっても、
そのクラスのソースコードはsrc.zipには含まれていない。
ところが！
公開されたJDKソースコードには、
しっかりとSunGraphics2Dが含まれている。
その関連クラスももちろん含まれていて、
｢メソッドを叩いてから描画されるまでの全てが手に取るようにわかる！｣
ようには、僕の修行が足りてないのでなっていないが、
大体の描画プロセスと各クラスの責務はわかってきた。
楽しい。

｢そこまでのこと知らなくていいよ｣な君は、
せめてデバッグ時にでも……いかが？

Spring Framework 2.0 Final Release！

Spring Framework 2.0のリリースがありました！

まだ詳しく見てないけど、はたして……。

小さな大発見

Javaの時期バージョンJavaSE6がやがてリリースされるのだが、
ベータリリースは既に実施されている。
最近は専らJava好きな僕としては、
ベータリリースであろうがなんだろうが、
とりあえずインストールして体感するのが趣味である。
(恐ろしいことに業務ではまだバージョン1.4を使っているのだ！)
JavaSE6はコードネームをMustangと言い、
正式名称はJDK6なのだが、
コードネームで呼ぶのが僕の周りでは一般的なので、
ここでもMustangと表記しようと思う。

さて、Mustang。
リリースを間近に控え、
雑誌やWebでも多く取り上げられている。
ところが、(僕の知ってる範囲で)雑誌には載っていないけれど、
個人的にはとっても素晴らしいアップデートを発見！

これまでのSwingでは、メニューバーをクリックして、
ポップアップウィンドウを表示した場合、
画面内のどこかの領域を選択して、そのポップアップを消していた。
だが、Windowsでは、メニューバーをクリックして、
ポップアップウィンドウを表示した場合、
タイトルバーをクリックすればポップアップを消すことができる。
僕はこのSwingの挙動が大嫌いで、
わざわざJFrame#setUndecorated(true)を呼び出して、
タイトルバーを表示しないようにして、
JPanelで擬似的にタイトルバーを作っていた。

が、Mustangではどうやら、
タイトルバーをクリックするとメニューのポップアップが消えるようだ！
どうでもいいように聞こえるかもしれないが、
そして、実際はどうでもいいのかもしれないが、
僕としては最高素敵なのだ！
(暇な人はMustang添付のサンプルを実行して確認してみよう！)

Mustangでは、
ウィンドウ最小化時にタスクトレイにしまえるようになったり、
Java2Dの描画パイプラインが最適化されたりと、
Swing好きにはとても素敵。
SwingWorkerの実装が見送られたのは残念だけど、
あまり人気のないSwingが未だにちゃんとアップデートされることに感謝！

JOGL

デスクトップが3次元になるのであれば、
アプリケーションが3次元にならないはずがない。
最も重要なことは、アプリケーションの3次元化により、
何がどうなって、それが誰にとってどんな風にどうか、だ。

たぶん、そんなことは、現状、わからない。
希望としては、
CUIからGUIに変化したのと同じだけの
ソフトウェア工学的な革命が起きて欲しいと思っている。
でも、それはまだ先のことになりそうだ。
特にハードウェアレベルでのステップアップが必要だ。
(それが空飛ぶマウスなのかどうかは知らないが)

だから、｢何がどうなって誰にとってどんな風にどうか｣は、
しばらくの間括弧で囲んでおいて、
3Dについて勉強していかなくては、と思う。

ということで、JOGLを始めてみた。
｢3DをやるならDirectXかOpenGLでしょう｣という青い発想と、
C言語/C++を離れてしばらく経っていることと、
C#よりもJavaに慣れているという理由で、JOGLの採用が決定。
個人的にSwingをかなり愛しているという理由も見逃せない。

さて、JOGL。
日本語の情報量が異常に少ないが、
ここに全12回で入門レベルのチュートリアルが掲載されている。
第12回はJOGLで実装されたAerithとういアプリケーションについて紹介されいて、
JOGLの実力を垣間見ることができる。
Aerithは今年のJavaOneの基調講演にもでてきたアプリケーションで、
Google Maps APIやFlickr APIとのマッシュアップをし、
ユーザインタフェースをSwingとJOGLで実現している。
(どうでもいいが、SwingでMashUpすることをSmashUpと言うらしい。素敵)

JOGLは日本語ドキュメントが圧倒的に少ない状況なので、
このブログでも出来る限りJOGLの情報は書いていこうかなと。
まぁ、JOGLはC言語のOpenGLラッパでしかないというのも事実なのだが。