今日の General Session は Oracle なので、パス。なので、今日は 9:30 はじまり。ちょっとだけ、ゆっくりできます。
さて、昨日聞いたところによると、朝食がランチボックスのようになっているらしいのです。それを教えてくれた人は初参加だったので、それが当然だと思ったようですが...
Alumni Lounge の朝ごはんは去年と同じだったので、Hall A だけのことなのでしょう。
さっそく、それを確かめるために Hall A にいってみました。
そうしたら、ランチボックスのようになっていましたよ。それも、ベーグルとマフィンが 1 つずつ入っているだけです。これはちょっとしょぼくないですか?
このように無造作においてあります
|
ベーグルとマフィン
|
ジュースは飲み放題です
|
|
今年も Java Man がいました
|
こんな風にコーヒを入れてくれます
|
さて、櫻庭が今日聴講したのは...
Technical Session
今日、よく理解できなかったのは TS-5535。JAX-RS に関するセッションですが、基礎知識が全然ないので、歯が立ちません orz
TS-5579 Closures Cookbook
Neal Gafter
Google の Neal Gafter のセッション。
Neal Gafter を中心にした、BGGA が提案する Closure について解説するというセッションです。ちなみに BGGA は Gilad Bracha, Neal Gafter, James Gosling, Peter von der Ahe の 4 人の頭文字です。
Closure はまだ JCP には提案されていませんが、提案の準備のためのサイト Closures for the Java Programming Language を立ちあげています。
彼らが提案する Closure の記法は { => } です。=> の左側に Closure の引数を記述し、右側に式を記述します。そして、Closure はインタフェースのインスタンスとして扱うことができます。
たとえば、次のように書くことができます。
Runnable r = { => doWhatever(); };
r.run();
Callable<String> cs = { => "result" };
Comparator<String> reverse =
{ String s1, String s2 => s2.compareTo(s1) };
ItemSelectable is = ...;
is.addItemListener(
{ ItemEvent e => doSomething(e, is); });
引数がある場合は、ちゃんと型を書きます。問題は戻り値の型を記述できないということですね。こういうときは、ジェネリクスで指定できるようなインタフェースにするようです。
Closure がよく使われる処理の 1 つにコレクションに対する処理があります。もちろん、Java の Closure でも提供されるようです。たとえば、sort、filter、map などがあります。
// aggregate code
final double highestGpa =
students.filter({ Student s => s.graduationYear==THIS_YEAR })
.map({ Student s => s.getGpa() })
.max();
昨日の Braian Goetz の Let's Resync セッションでも紹介されていましたが、このような形式を使うと並列化を自動的に行なうことができます。
ところで、コレクションに対する演算を Aggregate Operation という言葉で表していたのですが、これって一般的な言葉なのでしょうか?
さて、後半は Closure 導入に伴う、Java の文法変更に関して。特にジェネリクスの議論を行ないました。
というのも、Closure の内部で例外が発生する場合のハンドリングが問題になるからです。Closure では戻り値の型を記述できないのでジェネリクスを使用すると書きましたが、同じように例外もジェネリクスで記述するのです。
例外をジェネリクスで記述する場合、BGGA は <throws X> という記述法を提案しています。
たとえば、次のように記述します。
interface Block<R, throws X> {
R execute() throws X;
}
public <R, throws X> R time(String opName, Block<R, throws X> block) throws X {
long startTime = System.nanoTime();
boolean success = true;
try {
return block.execute();
} catch (final Throwable ex) {
success = false;
throw ex;
} finally {
recordTiming(
"opName", System.nanoTime() - startTime, success);
}
}
そして、この time メソッドを使うには次のように記述します。
int f() throws MyException {
time(“opName”, { =>
// some statements that can throw MyException
});
time(“opName”, {=>
return ...compute result...;
});
}
ところで、BGGA の提案が Java SE 7 に採用されると決まったわけではありません。BGGA の提案も他の意見を取りいれて、変化しています。この議論が収束するにはもう少し時間がかかりそうです。
TS-6185 Modularity in Java Platform
Alex Buckley
Stanley Ho
今年の JavaOne で最も多く聞かれる言葉がモジュールもしくはモジュラリティです。ということで、このセッションもかなり注目されていたようです。
このセッションは JSR 294 のスペックリード Alex Buckley と JSR 277 のスペックリード Stanley Ho がスピーカです。
モジュラリティには開発時とデプロイメント時の両方の側面があります。
既存の Java では開発時のモジュラリティとしてパッケージ、デプロイメント時のモジュラリティとして JAR ファイルがあります。
しかし、これらのモジュラリティだけではいろいろと問題があります。
たとえば、public が public すぎる点などがあります。内部的に使用したいクラスでも public としてしまうと、どこからでもアクセスされてしまいます。使用するクラスがパッケージが同じであればパッケージプライベートでもいいのですが、パッケージが異なっている場合はそれもできません。
JAR ファイルもバージョニングや、JAR ヘルの問題が存在します。
このような問題を解決するために導入されたのが、開発時の module とデプロイメント時の JAM ファイルです。
もともと、module は JSR 294 で superpackage として提案されていました。JAM ファイルは JSR 277 の提案です。しかし、これらの問題は双方に深く関係しているということから、JSR 294 は JSR 277 に統一されることになったようです。
それにともない、superpackage も module という名前になったわけです。
module というキーワードは 2 つの意味を持ちます。
1 つが複数のパッケージをまとめて、モジュールを構成するための module 文。もう 1 つが、モジュールの内部だけパブリックになるというアクセス修飾子の module です。
あるモジュールに属するクラスは次のように module 文でモジュールを指定します。
module org.netbeans.core;
package org.netbeans.core;
public class Debugger {
...
}
package 文と module 文が並ぶのでへんな感じですが、そういうものらしいです。ここでは、パッケージ名とモジュール名が同じですが、もちろん違う名前でもかまいません。
もう 1 つのアクセス修飾子としての使い方は次のようになります。
module org.netbeans.core;
package org.netbeans.core.utils;
module class ErrorTracker {
module int getErrorLine() { ... }
...
}
この ErrorTracker クラスはモジュールの内部だけは使用できるモジュールプライベートなクラスになります。また、getErrorLine メソッドも同様にモジュールプライベートなメソッドになります。
さて、モジュール自体の定義は module-info.java に記述します。上の例だと、org.netbeans.core パッケージに相当するディレクトリに module-info.java を配備します。
@Version("7.0")
@ImportModule(name="java.se.core", version="1.7+")
module org.netbeans.core;
module-info.java には Annotation でモジュールに対するメタデータを記述できます。
一方の JAM ファイルは、基本的には JAR ファイルの形式をそのまま使用しています。しかし、DLL やシェアードライブラリなどプラットフォームに依存したファイルもまとめられることや、依存している JAR ファイルも含めることができるなどの点が異なります。
また、JAR ファイルではメタデータは MANIFEST.MF にわずかしか記述できませんが、JAM ファイルでは上述した module-info.java に Annotation で記述することができます。これからも分かるように、JARM ファイルはモジュール端で作るようです。
たとえば、module-info.java の例を次に示します。
@Version("7.0")
@MainClass("org.netbeans.core.Main")
@Attribute(name="IDE", value="NetBeans")
@ImportModules({
@ImportModule(name="java.se.core", version="1.7+"),
@ImportModule(name="org.foo.util", version="1.0", reexport=true),
})
@ImportPolicyClass("org.netbeans.CustomPolicy")
@ModuleInitializerClass("org.netbeans.core.Init")
@PltformBinding(os="solaris", arch="sparck")
@ExportResources({"icons/**"})
module org.netbeans.core;
JAM ファイルの作成は jam コマンドでおこないますが、オプションなどは jar コマンドと同様のようです。
JAR ヘルを排除するために、JAM ファイルごとにクラスローダが割り当てられ、依存するライブラリがバージョン違いのものがあったとしても、名前空間で区別することができます。
また、レポジトリにも対応しています。
このレポジトリ用の API を使うと OSGi のモジュールも読み込めるらしいのですが、まぁ一時しのぎでしょうね。
これは櫻庭の意見ですが、やっぱり Sun は OSGi をまじめに取り組むつもりはないと思っているからです。
今年の JavaOne では OSGi がいろんなところで聞かれるのですが、どちらかというと Sun の外側の部分です。たとえば、Spring が OSGi に対応したとか。
もちろん、GlassFish が OSGi に対応することは知っていますが、本当に必要であれば Java EE 6 に入れるはずです。
なので、GlassFish の OSGi 対応も JAM が普及するまでのつなぎでしかないと櫻庭は思っています。でも、JAM の普及がいつになるかよく分からないですけどね ^ ^;;
とりあえず、OSGi を策定している JSR 291 では、Sun は常に反対票を入れてきたということは事実です。
さて、モジュールを決めている JSR 277 ですが、OpenJDK の Modules サブプロジェクトで開発が進められています。
TS-5199 Java Management Extensions (JMX) Technology Update
JMX のセッションは去年からそれほど進展がないようです。JMX 2.0 と Web Sercives Connector の解説ですが、すでに仕様はほとんど固まっているので、後は実装ということなのでしょう。
おもしろかったのは、Web Services Connector のデモ。
Web Services Connector は WS-Management と関係が深く、したがって Java 以外の言語からでも管理をおこなうことが可能になります。
デモでは、ポーカーの Web アプリケーションを VB で使った管理クライアントで管理するというもの。なにがおもしろいって、スピーカの Éamonn McManus と Jean-François Denise がいきなりサングラスをかけて、カジノっぽい感じで演じてたこと。こういう遊び心はいいですね。
Éamonn McManus
|
これがポーカーのシステム
|
カジノ風
|
後日談: Flickr で JavaOne の写真を公開しているわけですが、なんと Flickr のメールに Éamonn McManus からメールが!! 写真を blog で使わせてもらいたいとのこと。これは本当にビックリでした。
JavaOne report: JMX Technology と JavaOne report: Everything Else で私の写真が使われています。
BOF
これでもいちおう Java Champions の一員なので、Champions の BOF には出てみましたが、まぁこんなもんでしょう。なんとか、丸山先生を Champions の事務局をやっている Aaron に紹介することができたので、それだけでよしとしよう。
ついでに大渕さんの blog にもあるように、Sun SPT をもらえる算段もつけたことだし ^ ^;;
ちなみに、大渕さんは Aaron の英語は分かりやすいと書いてますけど、私には聞き取れない orz 彼はむちゃくちゃ早口なんです。
セッションの後、3 人で歩いていたら、Mark Hapner に遭遇。彼は私のことは覚えていないだろうけど、丸山先生とは周知の仲。Mark Hapner にごはんを誘われたのですが、次の BOF があるので遠慮させてもらいました。で、丸山先生と Mark Hapner で夜の San Francisco に消えたのでした。
もう 1 つの Modularity の BOF は Q&A セッションなので省略します。
BOF-5470 SwingLabs Development Update
SwingLabs は標準の Swing に含まれないツールなどが開発されています。たとえば、SwingX や Timing Framework、現在は Java SE 6 に含まれている SwingWorker などがあります。
このセッションでは主に SwingX と SwingX - WS の紹介がされました。
SwingX は Swing eXtensions のことです。SwingX には JXTable や JXLoginPane のように JX ではじまるコンポーネントがいろいろあります。
ここで紹介されたのが、SwingX Unified Renderer です。
JTable や JTree などうんたらレンダラーを使うコンポーネントがいくつかあります。今まではこれらのレンダラーは別々に実装されていました。
それを統合化しようというのが Unified Renderer です。Unified Renderer ではハイライトやソート、フィルターなど共通して使用できる機能を取り込んで、コンポーネントにかかわらず統一的に扱うことができるようになります。
次の Swing - WS は文字通り Web Services を Swing で扱ってしまおうというものです。個人的には、この方向性はあまり好きではありません。でも、こういうことをやりたいという人もいるんでしょうね。
ラベル: Java, JavaOne, お出かけ
