駅から５分

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に含まれないほうがよっぽど悲しい気がしてきた... 　 　

blogしばらく放置していたのでねたが古い古い。。。汗 もったいないので一応上げとく。 JavaFXは12月4日木曜の夜頃リリース。 intelの人の発音によるとNehalemはネハーレム,ネヘーラムというらしい。 glassfishV3はアプリに組み込み可能なライブラリ形式もあるらしい。 JavaFXはSwing,Java2Dの他に、Swing,AWTの上にSceneGraphという ライブラリを利用しているらしい。java.netにプロジェクトがあるとのこと。 先日、 Filthy Rich Clients を衝動買いした。 JavaFXで利用されている技術と関連する記述がありそうなので読んでみる。 (前半はJava2Dの基礎的な内容も書かれていて、私にはちょうどよい。 日本語版Effective Java Second Edition(第2版)買った。 オマケつきを期待して会場で本を購入したが、オマケではなく割引だった。 洋書販売もしており、皆さん当然のように読むのだなあと感心してました。 　 　

何か、closureの引数でワイルドカード使うとエラーになる。 詳しく調べてないけど、以下のコードはエラーになった。 (BGGA 2008-08-11版のclosure.jarでやってエラーになった) 　// × コンパイルエラー 　// "? supre T"の周辺で６つぐらいエラーが出る。 　public Integer calc({? super T,Integer} func) { 　　// ありゃエラーになる。 　} 　// ○ コンパイル/実行可能 　public Integer calc(Function<? super T,Integer> func) { 　　// これはＯＫ 　} んー　これは何か理由あっての制限なのかな。 それともこのバージョンは未完のためエラーになってしまうのかな。 英語だからってBGGAのページのドキュメントを読むのサボったから 見落としたのかな...。汗 　 　

ジェネリクスと配列の組み合わせは相性が悪い。 という件は、2007年のJavaOneのセッション「Effective Java Reloaded: This Time It's Not for Real」で言ってるね。 ちゃんと読み直せばO'Reillyの「Java Generics and Collections」にも 書いてあるかも。