きました。










RRoD。
これが出てやっと一人前の360ユーザー。
　
とはいえ、
来週、大規模アップデートあるのにこの時期はねーだろ。ヽ(｀Д´)ノ


ところでこの写真、HAL9000ぽく撮れてたんだけどかっこよくね？
　
　

コメント

コメントを投稿

このブログの人気の投稿

java7のロードマップ

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

リフレクション無しにjar間のクラスを解決する作りこみ

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のような動的な差し替えが起こらなければ、十分なわけで。 凝った機構を作りこむわけでもなく非常にシンプル。 よく知られた手法なのかな？ 些細なことなんだろうけど、私には到底思いつかないアイデアだなあ。 　 　
続きを読む

Arrays.asList()のジェネリクスの仕組み

以前、 ジェネリクスについて書いた とき、引数型に(T...)を利用するのは 相性悪いと書いた。 このときは、引数型(T...)を持つ、インタフェースを継承し利用したときを 例にした。 でも、JavaPlatformAPIの中にはArrays.asList(T... t)というメソッドもあった。 そこで、OpenJDKを開いてasList()のソースを調べてみた。 public static <T> List<T> asList(T... a) { 　　return new ArrayList<T>(a); } あれ？配列受け取る引数のコンストラクタなんてArrayList持ってたっけ？ と思ったらArraysコード内で同名の実装クラスを持ってった。 おおう。 List<T>が戻り値なのでこれを満たせば十分と。 なるほど。 このクラスの中身を見たところ、ジェネリクス配列そのものを内部に持ち、 単純なラッパークラスでした。 ArrayList<T>の様なコンテナとしての利用はＯＫでComparator<T>みたな 継承前提インタフェースでの引数型に(T...)を利用するのはアウトということか？ ふうむ... 余談ですが、Arrays.asList()の利用方法は、可変長引数からListクラスを 作るだけでなく、配列のラッパークラス生成の便利メソッドとしての 利用もよさそう。 　 　
続きを読む