 |
 |
|
|
今年は Sun の General Session が減って、初日と最終日だけになりました。その代わり、プラチナスポンサーの General Session が増えました。
今日は朝が Oracle で、夜が BEA。私はあまり興味のない分野だったので、両方ともパス。ほんの少しだけ、ゆっくりの朝です。
とはいうものの、朝から Alumni Club で情報収集。
毎日発行される JavaOne Today で、セッションの変更や追加セッションの確認をおこないます。
そして、他の人との情報交換は欠かせません。今日はオークランドでマリナーズの試合があるらしく、結構な数の人が見にいくのだそうです。
でも、BOF の最後の枠に Seasar のひがさんが登場するので、それまでには帰ってくるとのこと。うーん、みなパワーあるなぁ。
というわけで、今日聴講したセッションです。
この中でおもしろかったものについてレポートします。
今日も最後のセッションははずれでした。仕組みの解説かと思ったら、How To 系の話でした。やっぱり、Core の部分を Sun 以外の人が話すのは気をつけないと。
また、その前の Integrating XML Into the Java Programming Language は、BOF の Q&A と合わせたレポートです。実際に内容も相互補完の関係にあったので。
今日は朝から Joshua Bloch です。次の Puzzlers も Joshua Bloch なので、2 連チャンです。
そして、Effective Java ですから、これを聞き逃すわけにはいけません。Effective Java の本にはいろいろとお世話になったし。
今回は Tiger で導入された Generics に関するトピックが多くありました。
たとえば、Builder パターンでオブジェクトの生成を行なう場合、次のようなインタフェースを使用することで Builder を統一的に扱うことができます。
public interface Builder<T> {
T build();
}
この方式だと Class クラスの newInstance メソッドでオブジェクトの生成を行なうよりも安全で、かつ強力です。
Generics の制限付きワイルドカード (<? extends T> とか <? super T> など) は、読むために使用する場合は extends を使用し、書くために使用する場合は super を使いようにします。
たとえば、ショップがあって、その派生クラスとして飛行機模型屋と鉄道模型やがあったとします。複数個を買うためのメソッドでは extends、売るためのメソッドでは super を使用します。
public interface Shop<T> {
T buy();
void sell(T item);
void sell(Collection<? extends T> lot);
void buy(int numItems, Collection<? super T> myStuff);
}
飛行機模型を扱う店ではプロペラ飛行機であろうとジェット飛行機であろうと、飛行機であれば買うことができます。売るときは、お客が飛行機の模型だけでなく鉄道模型を集めいている場合でも売ることができます。
この関係を考えると sell は extends、buy は super となるわけです。
また、制限付きワイルドカードをメソッドの戻り値に使うことは混乱の元なのでやめるべきであるとか、ワイルドカードの使いすぎは間違いの元であるとか、配列と Generics をいっしょにつかってはいけないとか...
本当にたくさんの Generics に関する Tips がいっぱい。
でも、ワイルドカードがたくさん書かれた資料を見ていると、こちらの頭の中が ? でいっぱいになっちゃうんですよね。ここで話された内容をベースに Effective Java Reloaded を本にしてくれないかなぁ。
さぁ、次は JavaOne 名物の Puzzlers です。なんと部屋は Genral Session が行なわれる Hall B, C です。この部屋で普通のセッションをやるのは、Puzzlers ともう 1 つだけです。
それだけ人気が高いということなのでしょう。
たぶん、BEA や Motorola の General Session より、人が入っているのではないかなぁ。
今回の問題は Tiger Traps ということで、Tiger に関連したもの。しかし、問題自体は昨年の JavaOne Tokyo と同じでした。
とはいうものの、それでもまちがっている私はダメダメです ^^;;
問題を考えるのは大変だと思うのですが、これからもずっと続けてもらいたいセッションです。
Dolphin で導入される予定のスーパーパッケージです。でも、はっきりいってまだよく分かっていません。
去年の JavaOne で Dolphin の情報として friend が導入されるというのを聞いて、ギョッとしたのですが、今年はその言葉を聞かなくてほっとしていたのです。
しかし、去年 friend といっていたのが、このスーパーパッケージのことだったらしいのです。なおさら、分からなくなってしまいました。
ようは開発の時とデプロイメントの時ではパッケージングに求められるものが異なるということ。どちらにとっても都合のパッケージングを考えていきましょうというものらしいです。
で、書き方としてはこんな感じ。
super package com.sun.MyModule {
export com.sun.myModule.myStuff.*;
export com.sun.myModule.yourStuff,Interface;
com.sun.myModule.myStuff;
com.sun.myModule.yourStuff;
com.sun.SomeOtherModule.theirStuff;
org.someOpenSource.someCoolStuff;
}
うーん、よく分からん。
現在は言語レベルの話は JSR-294、デプロイメントに関しては JSR-277 で議論されているようです。
ところで、このセッションにあの Bill Shannon が聴講していました。やっぱり、パッケージングの話は Java EE にも通じるところがあるので、興味があるのでしょうか。彼はセッションが始まる前、一番前の一番右側の端っこの席で、パンをかじりながら USA Today を読んでいたのでした。どこの親父だと思ったら、Bill Shannon だったんでビックリ。
言語レベルで XML を扱っていきましょうという機能で、もちろん言語仕様の変更が入ります。スーパーパッケージも言語仕様の変更を伴うので、Dolphin はずいぶん言語仕様が変更されそうです。
すでに Java では標準で、DOM、SAX、StAX、JAXB の 4 種類の XML を扱うための API があります。この他にも JDOM なども入れるといくつかあるかさっぱり分かりません。
しかし、これらの API よりも、もっと直感的に XML を扱おうというのが動機のようです。
基本となるクラスは java.lang.XML クラスで、その他のクラスは java.xml パッケージに含まれます。 扱い的には文字列に近いような気がします。次の例は去年から何度も出てきていますが、とりあえず。
void addReviewer(XML feature, String reviewer, String time) {
feature.add(<reviewer>
<who>{ reviewer }</who>
<when>{ time }</when>
}
実をいうと、セッションで示されたコードは間違っていて、コンパイルできません。まぁ、本質的なところではないので ^^;;
{ } でくくられた中には数字や変数を直接記述できるようです。文字列も記述できますが、{ ] や " " でくくる必要はないようです。
<somevalue>文字列</somevalue>
というように記述できます。
しかし、ここで示した記述方法はまだ議論中のようで、タグを <> を使わずに # を使って記述する方法も示されていました。<> で表す方法は直感的に優れますが、すでに Java では <> をいろいろなところで使っています。演算子や Generics、特に Generics と見分けがつきにくい場合もあるかもしれません。
その他に、既存のクラスを XML 表現に変換するためのクラスや、ストリーミングのためのクラスも用意されているようです。
XML クラスの定義は次のようになるようです。
class XML extends Content {
Name name();
Map<Name, Attribute> attributes();
List<Content> content();
List<Node> nodes();
}
class Name {
URI ns();
String name();
static Name of(URI ns, String name);
}
class Attribute {
Name name();
String value();
Attribute set(String v);
}
class Text extends Content implements CharSequence {
Text set(CharSequence cs);
Text add(CharSequence cs);
}
class Content extends Node {}
class Node {
XML parent();
Node detach();
}
ここで説明したように、この機能を使用すると直感的に XML を扱うことができます。しかし、Validation などをどう扱うかなどいろいろと議論の余地は残っているようです。
セッションの最後に、会場に質問。XML を < > で表す記法がいいか、# { } を使用して表す記法がいいかというものでした。
私が思っているよりも # { } 記法の支援者が多かったのが印象的でした。
Meet the Swing, AWT, and I18N Teams は Q&A セッション。やはり、GUI 系はいろいろと文句を持っている人が多いですね。I18N に関する質問があまりにもないので、途中で I18N に関する質問はないのかと聞かれていました。
あれっ、なぜか壇上にいなくてはいけないはずの神谷さんが私のとなりにいるではありませんか。神谷さん、いいんですか、こんなところにいて。
Java Programming Language and Compiler Issues for the Java Platform ははずれ。もっと、javac やアノテーション関連でいろいろと説明することは多いと思うのですが... ほとんどの時間を Compiler API を使った地味なデモで終わってしまいました。
Seasar に関するセッションで、ひがさんと飯田さんが登場。
もしかしたら、日本人だけかと思っていたら、思っていた以上に外国の方が聴講していました。
内容自体は丸山先生レクチャーシリーズなどで講演している内容なのですが、最後にゴールデンウイーク注に実装したという Hotswap のデモが追加されました。
で、どうだったかというと、もう少しどうにかできたのではないかと思いました。
izu さんが指摘されていることは以外の部分で櫻庭が気づいたところは...
両方とも技術云々の話ではなくて、ポスチャーの問題です。内容がすばらしくとも、ポスチャーによって理解が妨げられてしまったらもったいないではないですか。
ポスチャーは技術です。性格とか、向き不向きとかは関係なく、技術なので、どうにでもなる問題なのです。欧米の人は小さい頃から、プレゼンテーションの訓練を受けてきています。それに太刀打ちしなくてはいけないのですから、もう少し考慮してもいいのではないかなぁと櫻庭は思うのでした。
とはいえ、それを櫻庭がやれといわれても、なかなかできないのですが... orz
今年からテクニカルセッションは事前登録制になりました。
去年もセッション会場に入るときには JavaCard で認識させてからでないと入れませんでした。今年はそれに輪をかけて、ちゃんと登録されているかどうかをチェックしています。
そのため、去年よりも会場に入るのに時間がかかってしまいます。初日ははじめてだったこともあり、どの会場も混乱気味。今日は JavaCard をチェックする WS も増え、かなりスムースいなりました。
とはいえ、どこでも行列なのは... ^^;;
今年はテクニカルセッションと BOF の間が比較的開いているため、今までに比べれば夕飯を食べる時間があります。でも、急いで食べなくてはいけないのは、やっぱり同じです。
逆に今年はランチの時間にもおもしろいセッションがめじろおしで、ランチを食べるひまがありません。結局、昨日、今日とランチを食べ損なってしまいました。
というのもランチ会場も長蛇の列なのです。こちらはセッションの合間にランチボックスを取りにいこうと思っていたのですが、そんなことは全然できそうもありません。
というわけで、ランチが食べられない... 明日は食べよう。
(May, 2006)