駅から５分

＼やべえ／ うかつだった。こんな分厚い本とは思ってなかった。 てっきりEffective C++ぐらいの厚さだと…。 それ以前にすでに積読があるってのにまた買っちまった…。

やった！ついにきたぜ、googleカレンダー　オフライン。 うれしいよー。 　 　

「セマンティクス」という単語をあちこちで見かけていたけど、 今までどんな意味かよくわかっていなかった。 シンタックス(文法)に対してセマンティクスは「意味」「意図」を 表現することみたい。 参考にしたサイト JavaA2Z ではアクセス修飾子protectedで作成者の意図を 表現する例を挙げた。 「意図した使い方は便利に、意図しない使い方は使いにくく設計する。」 というような言葉がどっかにあったと思うけど、これはセマンティクスを プログラムにしっかり織り込むことすすめている話なのかも。 他には... 多分引数にconstを記述するのもセマンティクスの話だろう。 javaでいうと@Overrideアノテーションとか。 プログラミング言語XXや言語入門～などの書籍はシンタックスを紹介し、 Effective XXのような書籍は良いセマンティクスを紹介しているんじゃないかな。 なんかこう、制約を課すような文法はセマンティクスを内包している感じがする。 　 　

NetBeansの利用ライブラリ一覧を眺めて、JNAなるライブラリを発見。 以前JNIについて調べたことがあったが、JNAはとっても便利そうだ。 .NETのP/Invokeっぽく使えてネイティブライブラリの資源が活用し やすくなったと思う。ブリッジ用DLLとか作る必要なくなって、 Javaから直接ネイティブDLLを呼んでいる感じになるみたい。 P/Invokeのときみたいなエントリポイントのエイリアスとかどうやるんだろ？ 今度サンプル作って試してしてみよう...。 CallBackを定義したJavaコードをネイティブで実行できるのは夢広がるなあ。 GPUで処理させたりできないかなあ。 少しいじってみたけど、どうやってこの仕組みを実現しているのか皆目 見当つかないなあ。 ということで、仕組みが知りたくなりソースを読んでみた。NetBeansの プロジェクトなのでNetBeans利用すすることでコードが追いやすかった。 ざっくりいうと、JNAは２層構造でJava側とネイティブ側がある。 Java側はjava.lang.reflect.Proxyクラスを利用している模様。Proxy クラスなんて初めて知ったが、JNAはこれを利用するサンプルとして いいかも。 ネイティブ側はlibffiという代物を利用している。ffiはforeign function interfaceの略らしいのだけど、これが良くわからん。 各種アーキテクチャ ごとのフォルダが並んでいるので、きっとバイナリコードを読んでメタ プログラミング的に定義されている関数を呼び出してくれる仕組みなんだ ろうけど...。 詳細はサッパリ。そもそも拡張子.Sのファイルって...。 私には無理だわ...。 そもそも読む気が起きない。 (^_^;) あとJNAの内部の仕組みについて、ウソ書いていたらごめんなさい。 　 　

当選した。 さあ、旅行の詳細計画立てないと。主に雨が降ったときの慰め観光を。 　 　

slf4j,logbackの仕組みから学んだ方法 ※既存のシステムに対して行うというより、これから作るjarモジュールの 　分割する方法として使える方法ですな。 api.jarとimpl.jarがあり、クライアントはimpl.jarの実装を直接触れずに api.jarだけ利用するような。インタフェースと実装を切り分ける構成の場合。 impl.jarのクラスの解決はClass.forName()などのリフレクションで行う。 この場合、ロードするクラス名を設定ファイル等でどこかに保持しておく 必要がある。 slf4jの仕組みでは、リフレクションを使わず、クラスパスでのクラス定義 解決を利用する。 １．api.jarはコンパイル時、スタブimplクラスをつくってコンパイルする。 ２．jar作成時、スタブimplクラスファイルを抜き不完全なjarを作成する。 ３．impl.jarにapi.jarで間引いた、implクラスを実装する。 これがimpl.jarのfacadeクラスに当たる。 ４．クラスパス解決時にapi.jarだけでは不完全のため、他のjar(ここでは impl.jar)の同名クラスで解決する。 これにより、実装とインタフェースを分けたモジュールを何の機構も 無しに解決することができる。 なんだかC/C++のリンクに似てる感じ。 後はimpl.jarがない場合のClassNotFoundException()だけ処理して アプリ自体が死なないようにすれば良いわけか。 javaだからこそビルド後"ファイルを間引く"という技が使えるわけで。 これはいいアイデアだ。 pluginのような動的な差し替えが起こらなければ、十分なわけで。 凝った機構を作りこむわけでもなく非常にシンプル。 よく知られた手法なのかな？ 些細なことなんだろうけど、私には到底思いつかないアイデアだなあ。 　 　

すでにあちこちで反応があるようですが、アップデートされたjava7の ロードマップの件で、クロージャが含まれないようですね。 　　 JavaLobbyの記事 　　 InfoQの記事 私はblogでクロージャのこと書いていたので余計切ないなあ。 でも前から賛否分かれているので、まあ仕方ないのかなあと。 それより気になったのが 　・Reified generics なにこれ？ "Reified"ってO'reilly「Java Generics and Collections」で盛んに出てきた 単語だけど... ちょっと調べた限りだと、型情報をRetentionPolicy.RUNTIMEでも保持し続ける ような仕組みらしいよ？ こっちの方がずっと重要じゃないか。 これがJava7に含まれないほうがよっぽど悲しい気がしてきた...