2008/05/08

JavaOne 3 日目

このエントリーをはてなブックマークに追加
Tommy Jr., Pavilion, JavaOne 2008

今日も General Session は自主的にパス。

今日は Pavilion の最終日なので、ちょっとだけいってみました。上の写真で、黒い車は Tommy Jr.。一昨年、出展されていた Tommy の最新型です。

Tommy Jr. も Tommy と同様、DARPA が主催している Urban Challenge に出場するため、無人で動作します。だから、Autonomous Vehicle Only なんです。こういうジョークは好き。

さて、今年もセッションに参加するには事前に登録が必要です。去年は Sun のワークステーションにリーダをつけて画面で確認するシステムでした。

今年はそれが小型化し、PDA で登録チェックをおこなっています。でも、やっぱり煩雑なんですよね。もっといい方法ないのでしょうか?

Session Registration, JavaOne 2008 Session Registration, JavaOne 2008

さて、今日櫻庭が聴講したのは

 

Technical Session

今日のセッションの中では、Extream GUI Makeover が今までとずいぶん違ってしまって、あまりおもしろくありませんでした。

去年まで、このセッションは Shannon Hickey と Romain Guy が主に担当していたのですが、全然知らない人。なんかちょっと残念です。

 

TS-5686 New I/O APIs for the Java Platform

Alan Bateman and Carl Quinn, TS-5686 New I/O APIs for the Java™ Platform, JavaOne 2008
Alan Bateman

Carl Quinn, TS-5686 New I/O APIs for the Java™ Platform, JavaOne 2008
Carl Quinn

J2SE 1.4 で導入された New I/O ですが、当初 JSR 51 で取りいれるといっていた機能には J2SE 1.4 に間に合わなかったのものがあります。たとえば、ファイルシステムに対する API などです。

これらの残された API を策定するために、JSE 203 で More New I/O APIs が提案されていたのですが、CAFE (Call for Exper Group) 以降、動きが全然ありませんでした。J2SE 5.0 は過ぎ、Java SE 6 も過ぎてしまい、やっと Java SE 7 で動き始めたというわけです。

JSR 51 のスペックリードは Mark Reinhold でしたが、彼は Java SE 6 (JSR 270) のスペックリードになってしまい、その後 OpenJDK の Govonor になってしまいました。

ということで、新しいスペックリードの Alan Bateman と、Google の Carl Quinn が登壇しました。

セッションは前半が File System API、後半が Channel に関する API です。

今までファイルを扱うのは java.io.File クラスだけでしたが、このクラスはあまりにも貧弱。扱えるメタデータもごくわずかだし、シンボリックリンクなどの特殊なファイルも扱えません。

そこで、新たに java.nio.file と java.nio.file.attribute パッケージが定義されるわけです。

主なクラスは次の 4 つ。

  • FileSystem
  • FileRef
  • Path
  • FileStore

普通にファイルを扱うには Path クラスでパスを指定して、チャネルやストリームをそこから取り出すという使い方になります。

import java.nio.file.*;
 
    Path home = Path.get("/home/gus");
    Path profile = home.resolve(".bash_profile");
 
    // Backup existing file
    profile.copyTo(home.resolve(".bash_profile.backup"));
 
    // Append useful stuff to the profile
    WritableByteChannel ch = profile.newSeekableByteChannel(APPEND);
    try {
        appendStuff(ch);
    } finally {
        ch.close();
    }

よく分からないのが、Path クラスと FileRef クラスの関係。Path クラスは FileRef クラスの派生クラスなのでしょうか?

JSR 203 はすでに Early Draft が公開されています。でも、Early Draft と微妙にというか、かなり違うのでよく分かりません ^ ^;;

この Path クラスはシンボリックリンクを扱うこともできます。また、ディレクトリを扱うための DirectoryStream クラスも用意されており、正規表現を用いたファイルのフィルタリングなども可能になっているようです。

ファイルのメタデータは FileAttributeView インタフェースで表されます。基本的なファイルのメタデータは BasicFileAttributeView クラス、POSIX に準拠したファイルであれば PosixFileAttributeView クラスで表すようです。

ファイルに対する操作が行なわれたときに発生するイベントも扱うことができます。これには WatchService インタフェースを使用します。

後半はチャネルに関する API です。

まず、ソケットでマルチキャストを行なうための MulticastChannel インタフェースが導入されます。

非同期 I/O は Selector クラスを使う方法しかありませんでした。それに対し、JSR 203 では Concurrency Utilities の Future インタフェースを使用する方法と、コールバックを行なう方法が追加されています。

 

TS-5419 The Garbage-First Garbage Collector

Paul Ciciora and Antonios Printezis, TS-5419 The Garbage-First Garbage Collector, JavaOne 2008
Antonios Printezis

Paul Ciciora and Antonios Printezis, TS-5419 The Garbage-First Garbage Collector, JavaOne 2008
Paul Ciciora

このセッションは新しい GC の手法 Garbage-First (G1) GC に関する物です。スピーカの Tony Printezis は GC の専門家。

皆さんよくご存じのように、現在の HotSpot JVM は世代別 GC が採用されています。世代別 GC では、ヒープを Young 領域 (Eden と Survivor) と Old 領域 (Tenured) に分割して管理を行ないます。そして、Young 領域では Copy GC、Young と Old を合わせた時には Mark & Sweep GC が適用されます。

今までの HotSpot VM では Young と Old は基本的には固定です (エルゴノミクスを使うと変化することがあります)。

ところが、ところが、G1 GC では違うのです。

G1 では、ヒープを小さい領域に分割します (現状では 1MB の領域だそうです)。そして、その領域のうちいくつかを Young 領域、残りを Old 領域に割り当てます。この割り当ては、連続している領域でなくても大丈夫です。

Young 領域がいっぱいになってしまったら、Survivor 領域に移動します (つまり Copy GC です)。このときに、Young から Old に移動するオブジェクトもあります。

Old のマークは領域ごとに行ないます。もし、リマーク時にその領域のオブジェクトがすべて GC 対象であれば、その時点でその領域は解放されます。

ここで、普通の M&S であれば、スイープに入るわけですが、G1 ではスイープは Copy GC と同じように行ないます。つまり、ある領域から使われていない領域にオブジェクトが移動させるわけです。移動元の領域は、その時点で解放されます。

もちろん、このような GC を行なうためには、各領域を管理する必要があります。このために、Remembered Set という領域を別途用意するようです。この領域はヒープ全体の 5% 以下なので、全体に対する影響は少ないようです。

今後はこの GC の手法が現在使用している GC に取って代わる予定だそうです。しかし、明確にいつということは言及されなかったので、Java SE 7 というわけには行かないかもしれません。

 

TS-6589 Defective Java Code: Turning WTF Code into a Learning Experience

William Pugh, TS-6589 Defective Java™ Code: Turning WTF Code into a Learning Experience, JavaOne 2008
William Pugh

今年はなんと Java Puzzlers がないのです。楽しみにしてたのに... でも、そんなに問題も思いつかないのかもしれません。

その代わりといってはなんですが、このセッションです。スピーカの William Pugh は FindBugs の作者であり、昨年の Java Puzzlers では Joshua Bloch と一緒に Puzzlers を担当していた人です。

このセッションも Puzzlers のように、サンプルコードを示してどこが悪いか説明し、モラルを説くというパターンです。でも、Puzzlers のようにパズル形式になっているわけではなく、サンプルコードも単体で動作するわけではありません。

しかし、示されたコードは JDK や Jetty などで本当に使われているコードです。これは興味深いです。

たとえば、Jetty で使われている以下のコードには間違いがあります。どこだと思いますか?

    private final String _lock = "LOCK";
        ...
    synchronized(_lock) {
        ...
    }

これは、ロック用のオブジェクトに文字列定数を使っているところが間違っています。

JVM では文字列定数は共有されてしまいます。そのため、異なる場所で "LOCK" という文字列定数を使っていたら、同じオブジェクトで共有されてしまうのです。

この問題のモラルは、何をシンクロナイズするかということより、誰がシンクロナイズするかを考えるべきだということです。

最後に、FindBugs のコンテストのアナウンス。

バグパターンを投稿して、優勝者には $200 だそうです。〆切は 8/31 です。

 

TS-6611 Filthy-Rich Clients: Filthier, Richer, Clientier

Chet Haase, TS-6611 Filthy-Rich Clients: Filthier, Richer, Clientier, JavaOne 2008
Chet Haase

Romain Guy, TS-6611 Filthy-Rich Clients: Filthier, Richer, Clientier, JavaOne 2008
Romain Guy

このセッションも JavaOne 名物といってもいいでしょう。Chet Haase と Roamin Guy のトークもおもしろいし、内容ももちろん役に立つものばかりなのです。

でも、Chet が Adobe に転職してしまったので、このセッションがあるかどうか不安だったのですが、あってよかったです。

最初の話題はアニメーションにおけるタイマ。

アニメーションは結局のところ、ある程度の時間間隔ごとに違う絵を描画するだけなので、時間間隔を制御するタイマは非常に重要になります。

でも、普通はタイマのことをあまり考えないので、タイマごとにスレッドを立ててしまって、スレッドが多くなりすぎという問題があります。

そこで、システムで唯一のタイマ用スレッドを用いることにします。

Timing Framework の場合は、Timer を指定できるので、シングルタイマを指定するようにします。すでに、Scene Graph プロジェクトのアニメーションではシングルタイマが使用されているそうです。

ちなみに、Timing Framework はもう役目を終えたということで、今後は Scene Graph プロジェクトのアニメーションに統合されていくということです。

次は Animated Layout。

コンポーネントのレイアウト変更をアニメーションでおこなったり、ドラッグ & ドロップをアニメーションでおこなうことに関して。櫻庭も Layout Manager を自分で書いたことがありますが、アニメーションさせようとは思いもしませんでした。

Flex 版は Chet の blog からダウンロードできるのですが、Java 版のコードが見たい! 公開してくれないかなぁ。

原型と呼べるものは、Filthy Rich Clients の本のサンプル (18 章) にありますが、ドラッグ&ドロップなどは実装されていないのです。

最後がクリッピング。

Java 2D にはクリッピングが用意されていますが、アンチエイリアシングが適用されないので、あまり綺麗ではないのです。そこで、クリッピングの代わりに Composite を利用する方法を紹介しました。

Java2D には Composite はちょっとしか用意されていないのですが、SwingX には 30 種類あるそうです。

 

BOF

Writing the Next Great Java Technology Book はなかなか興味深い BOF だったのですが、如何せん私の英語能力が追いついていないので、内容の半分も理解できていないと思います orz

柴田さんが blog でこのセッションに言及されていらっしゃるので、そちらをご覧ください。

 

VisualVM: Integrated and Extensible Troubleshooting Tool for the Java Platform

Luis-Miguel Alventosa, BOF-5223 VisualVM: Integrated and Extensible Troubleshooting Tool for the Java™ Platform, JavaOne 2008
Luis-Miguel Alventosa

Visual VM は TS-6271 Java Platform, Standard Edition: A Youthful Maturity でも紹介されていた jconsole とプロファイラがくっついたようなツールです。

実際は jvmstat、Attach API、JMX、Serviceability Agent の 4 つの技術を使い、モニタをおこないます。プロファイルは NetBeans Profiler から必要なものだけを選択したバージョンのようです。

すでに VisualVM は java.net で公開されているので、興味があるのであればぜひ使ってみてください。

VisualVM https://visualvm.dev.java.net/

 

After Dark Bash

Smash Mouth, After Dark Bash, JavaOne 2008

BOF の最後のコマはおもしろそうなのがなかったので、帰ろうと思ったのですが...

そういえば、Yerba Buena Park で After Dark Bash をやっていることを思いだしました。ここ数年はあまりメジャーな人はいなかったのですが、今年は結構メジャーなバンドのコンサートなのです。

ちなみに、かつては Train のコンサートもあったりしました。

で、今年は Smash Mouth のコンサート。彼らは 1994 年に結成ということなので、10 年以上もキャリアがあるのですが、櫻庭が知っているのは I'm a Believer のカバーと All Star ぐらい。I'm a Believer は映画のシュレックで使われています。

Yerba Buena Park は Moscone North の上。Moscone North はレジストレーションがある地上部分以外はすべて地下にあります。で、その上が Yerba Buena Park となっているわけです。

で、Yerba Buena Park にいってみました。

9:00 までの予定なので、また演奏しているか微妙だったのですが、まだやっていました。とりあえず、写真、写真。

久しぶりにライブの生演奏を聴きましたけど、やっぱりいいですねライブは。

それにしても、寒い。ほんと凍えそうです。連日のハードワークで疲れが残っていたのですが、この寒さが引き金でとうとう風邪をひいてしまいました orz

Smash Mouth, After Dark Bash, JavaOne 2008 Smash Mouth, After Dark Bash, JavaOne 2008
Smash Mouth, After Dark Bash, JavaOne 2008 Smash Mouth, After Dark Bash, JavaOne 2008
Smash Mouth, After Dark Bash, JavaOne 2008 Smash Mouth, After Dark Bash, JavaOne 2008

2 件のコメント:

匿名 さんのコメント...

JavaOne 名物のセッション「Filthy-Rich Clients: Filthier, Richer,Clientier」、見事に見逃しました。(涙 もっとJavaOne前に情報入手しておけばよかったです。さくらばさんにおすすめセッション聞くとか。(笑
来年は後悔することが少なくなることを期待しつつ・・・

Yuichi Sakuraba さんのコメント...

確か...

> それは、 ロックスターとチャンピオン に注目すること!です。

と誰かが書いていたはずですが、Chet も Romain も Rock Star なんですけどね ^ ^;;

でも、聞きそびれたセッションというのは少なからずありますよ。あんなにパラレルにセッションがあったら、聞きたいセッションが重なることも多々あるし。