netail.net

_ AspectJ ▲

AJC1.1alpha がもうすぐリリースらしい．主な特徴は以下の通り．・コンパイル時，リンク時，クラスロード時の weaving を可能に（.jar も扱える）・eclipse.org のコンパイラによる再実装・アスペクトのバイナリに，ソースと同等の すべての情報を保存するようになった・インクリメンタルコンパイルの実装これでさらに面白くなりそう＆面倒が起きそうな予感．

_ robocode ▲

JNI を使って Win32 API の getKeyboardState を呼び出し，ロボットをユーザが動かすことができるか？という実験をしてみた．

ユーザがコントロール可能なロボットは，強化学習などで使えるかもしれないなーとか，別のゲームとしても遊べそうだなーとか思ってたんだけど……

結果は，「System.loadLibrary への呼び出しを妨害しました」という旨が java.security.Permission によって出されておしまい．まぁ，robocode の趣旨的にはすごく正しい反応だ．Java 以外の機能使うのはある種のインチキだし．

手間かけて DLL とか作ったわりに結局役に立たなかったので少し残念ではあるけれど，Security Manager が有効に動作してる環境は初めて見たので，感動した．

_ JNI ▲

Java Native Interface を使ってみた．使い方をいちおうメモ．・native メソッドをクラス側で宣言・javah でヘッダファイルを生成・ヘッダファイルを使って VC などで DLL を作成　（インクルードパスに C:\jdk1.3.1\include などを通しておく）・DLL を java.library.path のパスのどこかに置く （または実行時に java.library.path を設定する）・System.loadLibrary("hoge") をクラス初期化時などに呼び出す　（Windows なら hoge.dll が読み込まれる）

_ 論文 ▲

Stephan Herrmann:Object Teams: Improving Modularityfor Crosscutting CollaborationsNet.Object Days 2002

を読んだ．Object Team というモジュール単位を導入している．Aspectual Collaboration に近い概念(?)で，Team class 側は「こんな参加者がいるよー」と宣言して，個々のクラス側は「私は Subscriber 役をやります，メソッド xxx は私のこのメソッドに delegate してね」と宣言する．依存関係が AOP の場合と逆．

で，クラス側が「この Team を active にしてブロックを実行」というようにコントロールできるみたいではある．登場人物となるオブジェクトが全員揃った状態でオブジェクト間の関係を明示しながらプログラムを書くことになりそうなので，1:n あるいは m:n のオブジェクト対応をどう扱うのか，とかちょっと気になる．

個人的には，アスペクトと併用してTeam オブジェクト記述→ Team に参加するオブジェクト記述→ オブジェクト間のルールをアスペクトで記述なんてやってみたい．

アプローチ自体は嫌いじゃないのだけど，プログラム言語を作ったことで，どのくらい複雑さが低減できるのか，とか抽象度が高い記述が可能なのか，とか色々議論する余地は多そう．

すべての振る舞いを Object Team で書いたらどうなるか，っていうのを見てみたいところ．

_ 論文 ▲

以前読んだ論文の読み直し．Behavioral Specification and Analysis of Object-Oriented Designs (1997)Boumediene Belkhouche, Joel WuJournal of Object-Oriented Programming

Object Oriented Design Language (OODL) という形式記述言語とその検証系を説明した論文．オブジェクトがやり取りするメッセージやそれに伴う状態遷移を記述して，オブジェクト間の依存関係の循環や，結合度，client/server 関係といったものを調べる．しかし，ソースコードとの対応関係の確認はできない．

_ カメラ ▲

部室にカメラを設置してみた．15分間隔で画像を撮影して，1MB/h で画像ファイルを生成する．カメラと新しいLANケーブルなどを買ったので微妙に出費．

アクセス方法は部員専用Wikiに掲載しておく．

_ [hyCalendar] プリンタでの印刷ミスへの対策 ▲

期間予定の直線の描画だけが消えるという報告があったので，調査した結果，Printer.Canvas.Font.PixelsPerInch の値によって線の太さを調節している処理で，もし，その値が正しく返されていなかったら，実は直線の描画がまったく起きない可能性があるということが判明．で，いちおう対策はしてみた．もし，それ以外が原因だったら，もう打つ手なし．

_ [お出かけ]オフ会＠なんば ▲

オフ会といっても，前日の晩に連絡があって大阪近郊で４人集まって遊んできただけではあるが :-)

たまたま御堂筋パレードが開催されてるところを通過したので，ちょっとだけ見物もしてきた．

_ [論文] AOASIA2006関連その１：Obliviousness ▲

ぼちぼちAOASIA関連の話題を整理してます．この記事自体は，正確にはAOASIA前日の別ワークショップで話された内容です．とりあえず研究関連ってことで論文カテゴリに入れておきます．

Obliviousness というのは，「アスペクトを結合するコード（クラスなど）はアスペクトの存在を知らない」といった意味なのですが，これが「クラスのコードは，アスペクトのコードへの参照を含んではいけない」という構文レベルでの話なのか，「アスペクトがなくても動くようなコードを書く」「クラスの開発者はアスペクトの存在を知らなく良い？」とかいう意味的な話なのか，というところが実は曖昧でした．

結局，使ってる人によって意味合いが違っていたようで（おかげでだいぶ議論が混乱していましたが），ベースコード中ではアスペクトの要素を参照しないという構文的な意味が AOP においては必須の性質であろう，意味的な Obliviousness の達成は望ましいが必須ではない，という形で整理されました．

意味的な Obliviousness としては，たとえば性能計測のような完全に後付けのアスペクトは，Obliviousness を達成する必要がありそうです．また，クラスから見た場合，別アプリケーションで再利用したいクラス群というのはアスペクトがあってもなくても動く必要があるでしょうし，アプリケーション固有のクラスは，そのアプリケーション内にいるアスペクトのことを多少意識したコードになっていても問題ない気がします．今のところ，構文的な参照関係以上の明確な指針はありません．