 |
 |
|
|
今日の General Session は IBM と Motorola。
だいたい、General Session ではエグゼクティブが話すのが普通だと思うのですが、何と IBM の General Session は Eric Gamma。GoF の Gamma です。
普段はプラチナスポンサーの General Session は聴きにいかないのですが、 Gamma と知ったらいかずにはいけません。
というわけで、今日聴講したセッションです。
というわけで、Eric Gamma です。もう 1 人、やはり Gamma と同じく Rational の John Wiegand。
だいたい、プラチナスポンサーの General Session は、その企業の事業戦略とか製品の紹介とかになるのですが、この General Session は違いました。
製品の話はまったくありません。それだけでも、すごいことです。
で、肝心の内容ですが、Eclipse の開発プロセスに関するものでした。Rational なので、UP 系のプロセスなのかと思ったらとんでもない。バリバリにアジャイルしてます。
彼らが話すととても納得してしまうのはおもしろいところです。
Eric Gamma のプレゼンテーションは、わざと定石を外したようなところがあって、おもしろいです。Gamma と Wiegand が交互に話すのですが、Gamma は Wiegand が話している間腕組みをして仁王立ちし、目を伏せています。普通、こんな待ちかたしないですよね。でも、それが味になってしまっているのは、キャラクタによるところが大きいです。
こういうことができればいいんですけどね。はぁ〜。
Apache Harmony のセッションはちょっとはずれ。この日が、Harmony Project が立ち上がってちょうど 1 年目の誕生日らしいのですが、ちょっとトーンが後退したような気がします。
Extreme GUI Makeover はおもしろかったのですが、既知のことばかりだったのです。というわけで、その他の 3 つのセッションについてレポートします。
Dolphin で導入される新しいバイトコードと Hotswapping に関するセッション。
どちらも、スクリプト言語のサポートを容易にするための変更。 特に新しいバイトコードは今までの Java の強い型付け言語という特徴を崩してしまうかもしれないような重大な変更だと感じます。
現在のメソッドを実行するためのバイトコードは
の 4 種類あります。そこに新たに、invokedynamic というバイトコードが追加されます。invokedyanmic は invokevirtual を弱い型付けに対応させたものに近いバイトコードです。
もともと、invokevirtual はオーバロードされたメソッドに対するメソッドでしたが、型は静的に決まります。
それを invokedynamic では型情報を後から与えることができるようになります。つまり、弱い型付けに対応できるようになるわけです。これにより型安全性をコンパイル時に保証できなくなりますが、ポインタやメモリに対する安全性が保証されていることの方が重要です。
ただし、このことがすべてのスクリプト言語に対応できるための答えということではありません。
たとえば、多重継承などはサポートしていません。また、スクリプトから Java のライブラリへのアクセスもいろいろと問題が残っています。
とはいうものの、invokedynamic を導入することで、 現状に比べれば容易にスクリプト言語に対応できることは確かです。
さて、次の Hotwapping です。これもおもしろい。
Java では一度クラスローディングしたものを、新たにクラスの定義をし直すことは難しいのです。あまり知られていないことですが、JVMTI を使用するとクラス定義をアプリケーション実行中に更新することができます。
しかし、JVMTI ではメソッドのシグネチャを変更することはできません。また、メソッドを追加/削除したり、フィールドの追加/削除をすることはできません。
あくまでも、メソッドの実装を変更することしかできないわけです。
そこで出てくるのが Hotswapping です。
これに対し、Lsip や Smalltalk ではアプリケーションの実行中にクラスの定義自体を変更してしまうこともできます。これが Hotswapping です。
スクリプトでは後からメソッドを追加したりするのはかなり自由に行えますし、クロージャに対応しているものを多くあります。Hotswapping を使用することで、このような動的な部分を補うことが可能になります。
しかし、この一方で Hotswapping を使用することでパフォーマンスはある程度犠牲になりそうです。まぁ、それはしかたないことではありますが。
まだ、どのように Hotswapping を実現するか、またどの程度の自由度を認めるかなどは決まっていないようです。
しかし、このような動的言語を直接サポートできるように Java VM が変更を加えられるというのは非常に興味深いところです。
Java VM が .NET の CLR のように、Java だけでなく複数の言語のための VM になる日もあるかもしれません。
JAXB といえば、川口耕介さん。たまたまですが、JavaOne の会期中に IPA の未踏ユースでスーパークリエイターに認定されたという嬉しいニュースも。
さて、JAXB ですが、JavaOne Tokyo でも、JAXB 2.0 のセッションがあったので、それ以外で櫻庭が興味を持った部分を。
たまたまですが、このセッションで Sun の藤井さんといっしょになりました。藤井さんと私は興味のある分野が異なるので、セッション会場でお会いするのはとても珍しいのです 逆に神谷さんとはとてもよく会うのですが ^^;;) 。
で、セッションを聞いていると、藤井さんが実を乗りだして興味深そうに聞いている部分と、私が興味がある部分が全く違うということに気がつきました。 藤井さんはツールでの JAXB のサポートなどに興味があるようすで、私は XJC のプラグインやアグレッシブモードに興味があります。1 つのセッションでも興味の違いがこれほど表れるとは思いませんでした。
さて、その私が興味をもったプラグインとアグレッシブモードです。
プラグインというのは、XML Scema から Java のクラスを作成する XJC のプラグインです。 XJC では Java のクラスを作成するのですが、このときに生成するコードを変更したり、異なるコード生成を行なったりするために使用されます。
もちろん、自分でプラグインを作成することも可能です。ただし、これは Sun が提供する JAXB だけの特徴で、他の JAXB 実装では動作しないようです。
例としてあげられたのが、JAXB で生成されたクラスに対し、setter で属性をセットするのではなく、StringBuffer 風にできるもの。これを少し変更すれば、昨日の Effective Java Reloaded で言及されていた Builder パターンを使用したオブジェクトの生成も可能になります。
また、アグレッシブモードは JAXB でのコード生成を可能なかぎり最適化してしまうというもの。このため、アグレッシブモードで生成したコードから XML Schema を生成しても、同じものにはなりません。
しかし、用途がはっきりしていて、性能が求められるような場合には使える機能です。櫻庭的にはこれをどうやって実現しているかに興味があるのですが、これは自分で JAXB のコード見て勉強します。
HotSpot VM の最適化に関するセッション。
すでにここまでくれば十分といえるほどのパフォーマンスですが、それでもまだ最適化するところはあるのですね。このセッションでは、同期の最適化とエスケープ解析がメインのトピックでした。
Java VM ではロックを軽量ロックで実装されていることが多いのだそうです。ほとんど競合が起きない場合には、軽量ロックは有効に作用します。
しかし、マルチプロセッサ時のアトミック処理のコストが高くなることや、同一スレッドで複数回ロックを取得しにいくことがあることなどが知られています。
そこで、登場するのが Biased Locking です。
Biased Locking では、スレッドがオブジェクトをロックする前に、オブジェクトをバイアスしておきます。こうしておくことで、同一スレッドからのロックはコストをかけずにおこなうことができます。
他のスレッドが同じオブジェクトをロックをしようとした場合、バイアスは破棄されます。
Biased Locking を導入することで、競合しない同期化のパフォーマンスが向上します。 Biased Locking はすでに Java SE 5.0 update 6 で導入されているそうです。
ちなみに、Tiger からは update バージョンでバグフィックスだけでなく、パフォーマンス向上も図られています。
次のエスケープ解析はオブジェクトをヒープでなくスタックにアロケーションするための技術です。オブジェクトがメソッドの中から逃げないかどうかを示すために使われている言葉がエスケープです。
たとえば、文字列連結の StringBuilder クラスやオートボクシングで暗黙的に使用されるオブジェクトなどは、メソッド内で完結している場合が多くあります。
このようなオブジェクトをスタックにアロケーションしてしまうというのがエスケープ解析です。この昨日は Mustang に搭載予定で、Dolphin でさらなる進化を予定しているそうです。
その他には sychronized を外してしまうとか、 配列のコピーの高速化、Server VM と Client VM の動的な変更などが、Mustang ではおこなわれているそうです。
今日、聴講した BOF は Java Champions に関するもの。神谷さんの blog で、とても居心地が悪かったと書かれたセッションです。
で、なぜ私がここに出席したかというと、私自身 Java Champion だからなのです ^^;;
ちなみに神谷さんの blog に書いてあったポロシャツを私も持っているのですが、まさかみんな着てくるものだとは全然知りませんでした。知っていても着なかったと思いますが (java.net の Java Champions のプロジェクトサイトにそのときの集合写真がのっていますが、私だけ普通のカッコです)。
ついでにパスの下に Java Champion の札までつけてくれました。
Java Champions のような活動は非常に重要だと思うのですが、できるだけオープンにしなくてはいけないのが問題かもしれません。今は、Java Champion の選出がクローズで、外部の人からは見にくくなってしまっています。
ようは Java Champions の ML で推薦があった人に対して Vote するのですが、Champion にはその過程は分かっても、外部には分かりません。
こうなると、結局英語圏の人ばかりになってしまうのですね。日本でも私 1 人ですし。アジアを含めてもほとんどいません。
もう 1 つ、日本が不利なのは JUG がないということ。JUG は Java Users Group です。なぜか、日本には JUG がないのです。
日本の Sun もこれから Champion を選出していく意向があると聞いたので、今後は Champion が増えていくでしょう。後は JUG ですね。
今日は Harmony のセッションの前に、なんとか Lunch Box だけは死守しました。でも、そのまま Harmony のセッションに出てしまったので、ランチ会場では食べられません。
ランチというより夕飯の時間になってしまいましたが、まだ日の高い Yerba Buena Park の芝生で食べようと思ったわけです。 そうしたら、たまたま Menasse と石原さんに遭遇。
Menasse がお気に入りの店を紹介してやるというで、のこのこととついていったら、ビアードパパでした。日本のシュークリームのビアードパパがたまたま先週、サンフランシスコにオープンしていたのです。
オープン直後だったためかすごい混雑。日本ではもうピークの過ぎた感のあるビアードパパですが、サンフランシスコではこれからなのでしょう。
ちなみに店の写真は違う日に撮ったものです。写真を撮ったときは午前中だったので、比較的空いていたのでしょう。
(Jun, 2006)