JavaOne参加レポート (9/23)

それでは2日目となる9/23のレポートについてまとめます。
この日からが本番と言った感じで、朝から晩までびっちりとセッションが埋まっています。結構ハードです。

この日に参加したセッションは以下の通りです。

• All the Nodes That Are Fit to Print: A Tour of the New JavaFX Printing APIs [CON2662]
• Securing JAX-RS RESTful Services [CON5179]
• Architecting Enterprise JavaFX 8 Applications [CON2229]
• Introducing the Java Time API in JDK 8 [CON6064]
• Type Inference in Java SE 8 [CON8165]
• Lightning-Fast Access to Big Data [BOF5957]
• JAX-RS and JSON Binding: Past, Present, and Future [BOF5519]

Java SE、Java EE、JavaFX をまんべんなく取りました。型推論のセッションがちょっと自分には難易度が高かったですね。

All the Nodes That Are Fit to Print: A Tour of the New JavaFX Printing APIs

JavaFX8 でようやく印刷のためのAPIが導入されました *1 。それについて解説するセッションでした。
JavaFX8 の印刷 API は開発者向けには分かり易い API を提供し、業務アプリケーションに要求されるレベルを満たすことを目標として設計したとのことです。

中心となるクラスは javafx.print.package.PrinterJob クラスで、このクラスが印刷ジョブを制御します。
このクラスの showPrintDialog() メソッドで画面に印刷設定ダイアログを出し、printPage() メソッドに印刷したい範囲のシーングラフを渡します。そして startJob() メソッドで印刷ジョブを開始します。
印刷ダイアログは、独自のダイアログをだしてエンドユーザーに嫌われることが多かったSwingの時の反省から、プラットフォームネイティブなダイアログを出すようにしています。

他に重要なクラスとして、プリンターデバイスを表す Printer クラス、プリンターの機能に関する情報 (サポートしている用紙サイズとか) を保持する PrinterAttribute クラス、印刷ジョブの設定 (サイズ、枚数、色など) を保持する JobSettings クラス、印刷レイアウトの情報 (ページ方向、マージン、 Node の表示範囲など)を保持する PrinterLayout クラスがあります。

デモをあり、JavaFX で描いた円や、JavaFX8 に付いてくる新しい Ensemble アプリケーションのサンプルを印刷する様子を見せてくれました。なお、新しい Ensemble には印刷ボタンが付いています。

総じて中々使い易そうな API だと感じました。現在は Java2D の印刷機能をベースに実装しているようです (WebView については WebKit のプリントレイアウトエンジンを使っている) 。そのため、Java SE 8 のフルプロファイルが必要となります。将来的にはリライトしたいとのことです。
今後は、よりプリンターフレンドリーに、また CSS にも対応して、HTML のように media=print と書けるようにして、画面と印刷で別のスタイルを定義するようなことをやっていきたいとのことでした。

Securing JAX-RS RESTful Services

JavaEE7 に含まれる JAX-RS2.0 について、サーバーサイドの認証/認可、クライアント API 側の認証、そして JAX-RS サービスで OAuth 認証に対応する方法について解説するセッションでした。

サーバー側の認証/認可についてですが、サーブレットコンテナが用意している仕組みはそのまま使えます。この方法は記述が冗長であり、メンテしにくいと言う欠点があります。
JAX-RS では SecurityContext を用意しており、@Context アノテーションでインジェクトできるようになっています。このオブジェクトを使えば、メソッド内の特定の範囲だけ認可の仕組みを入れるなど、柔軟な制御が可能になります。
また、javax.annotation.security パッケージには @PermitAll などと言った認可のための各種アノテーションが用意されており、クラスやメソッド単位で宣言的に認可の設定を行えるようになっています。
また、Jersey2 + MOXy 限定ですが、Entity フィルタリングという機能が用意されています。これはリソースメソッドが返すエンティティのプロパティにアノテーションを貼って、アクセス元の権限に応じてエンティティの特定の属性だけを見せない、といった制御を可能にする機能です。

次にクライアント側についてです。
まず SSL で保護されたサービスにアクセスするために SslConfigurator というクラスが用意されています。ここにキーストアファイルなどの設定を行えます。
認証が必要なサービスへのアクセスですが、Jersey にはリクエスト、レスポンスをフィルタするための ClientRequestFilter、ClientResponseFilter というものがあります。そして、Web サービス側の認証方法に応じた、BasicAuthFilter や OAuth1Filter、OAuth2Filter が用意されていて、これら認証処理に容易に対応できるようになっています。

最後に JAX-RS (Jersey) を使って構築した Web サービスが、OAuth による認証を行う第3者サービスを利用する方法についての解説がありました。
Jersey では OAuth1.0a、2.0 をサポートしており、それぞれ OAuth1AuthorizationFlow, OAuth2AuthorizationFlow というクラスが用意されています。
この Flow オブジェクトにリダイレクト URI やプロンプト方法、識別子を設定し、 start() メソッドで認証を開始します。
そしてサービスプロバイダからコールバックしてもらうためのリソースメソッドを用意し、このメソッドの中で Flow オブジェクトが取得できると認証が成功となります。
実際に Google Task サービスにアクセスするデモを行って見せてくれました。

Architecting Enterprise JavaFX 8 Applications

Adam Bien さんによるセッションです。JavaFX でエンタープライズ向けアプリケーションを構築する際のアーキテクチャはどうあるべきか、そしてその考え方を実装した自身作のフレームワークである afterburnerfx の実装について説明を行ってもらいました。

一般的に GUI アプリケーションのアーキテクチャとしては Smalltalk 由来の MVC パターンが良いとされています。しかしながら、近年になって複雑化する一方の GUI アプリケーションにおいては不十分であると考えられるようになってきました。
特にアプリケーションのリッチ化が進むにつれて、View 側のロジックが複雑化する一方です。View のテストは難しいです。そこで、MVC を変形したパターンとして、MVP (Model View Presenter) パターン、Presentation Model パターンなどといった新しいパターンが出てきました。 *2
MVP パターンは簡単に言うと Controller に View を操作する役割を持たせたパターンで、Presentation Model パターンはプレゼンテーションに関連するステートを保持する Model (Presentation Model) 用意し、View と Model の間に置くというパターンです。

JavaFX では FXML という仕組みがあります。FXML はマークアップ側 (View) と1対1で結びつく Controller が存在し、@FXML アノテーションで View 側のコントロールを Controler にインジェクション、さらにメソッドに対しても @FXML アノテーションで View 側で発生したバインディングさせることができます。
よって、FXML の Controller は MVP パターンにおける Presenter の役割を持たせることができます。
さらに JavaFX にはバインディングという優れた仕組みがあるため、Presentation Model を用意すれば、バインディングを利用することでプレゼンテーション側の実装コードを減らすことができるようになります。
そこで、afterburnerfx では次の図の様なアーキテクチャを取っています。

Presenter はサービス (主にネットワーク経由で外部サービスからレコードを取得するコンポーネント) と Presentation Model にアクセスします。サービス経由で取得したデータで Presentation Model をアップデートし、View は Presentation Model のプロパティとバインドしているので、自動的に表示が更新されます。
各コンポーネントの結び付けは afterburnerfx 独自で開発した DI の仕組みを使って結びつけています*3 。FXMLLoader には setControllerFactory() というメソッドがあり、ここをフックして Presenter に対してサービスや Presentation Model のインジェクションを行うようにしています。View と PresentationModel のバインドは Presenter が行います。
View の更新はバインディングを利用して極力 PresentationModel のステート変化だけで行えるようにし、イベントハンドリングは FXML のメソッドバインドを使って Presenter のメソッドをそのまま呼び出すようにすることで、JavaFX 固有の API への依存が減るため、よりテスタブルになるというわけです。

JavaFX ではこれまでこのような本格的な GUI アーキテクチャに関する話があまり出ていなかったので、とても興味深いセッションでした。こういう議論が出てくるようになったということは、ある程度 JavaFX が普及期に入りつつあるといえるのかも知れません。

Introducing the Java Time API in JDK 8

Java8 で新たに導入された Date Time API (JSR-310) について、スペックリードの Stephen Colebourne 自身に説明してもらうというセッションです。とりあえず噂の Colebourne さんのお顔が拝めただけでも良かったと思っています。

Date Time API はイミュータブル、流れるような API、明確な API であることを目標として設計したとのことです。日付や時刻を取り扱う上で登場する概念をきちんと分類して、対応するクラスを用意しています。
おかげで沢山の種類のクラスが登場します。日付を表す Date クラス、時刻を表す Time クラス、両方を組み合わせた DateTime クラス、そしてこれらには Local**、Offset**、Zoned** クラスが用意されます。
そして時刻のある時点を指す Instants、時系列に縛られない時間の量を表す Amount (時刻ベースは Duration、日付ベースは Period) といったクラスもあります。
これらクラスにはインスタンスを取得するための now() メソッドや of() メソッド、各種演算メソッドや変換メソッドなどが用意されています。メソッドの意味は比較的明確で、メソッドチェーンができるようになっているので、流れるように記述されます。

各所で色々言われているように、覚えることが多くて大変かもしれませんが、API の意図は非常に明確であるので、個人的には以前のひどかった API よりは随分良くなったと思っています。
Colebourne さんはセマンティクスを明確にすることを重視される方に見受けられました。後日セッションがあった Colebourne さんが中心になって仕様を策定しているの Money and Currency にもそれが良く現れていました。
やっぱり仕様を考えた人のお話を直接聞くというのは理解する上でとても価値があるなあと思いました。

Type Inference in Java SE 8

Java SE 8 での型推論についてのセッションです。私自身が型システムに対して不勉強なこともあり、ちょっと難しい内容のセッションでした。

基本的に Java には型推論はありませんが、型パラメータの指定部分だけではちょっとだけ推論が効きます。Java SE 7 のダイアモンド演算子がそうですね。ただ、Java SE 7 ではこの推論が余り賢くなく、メソッド引数では効かなかったりしていました。それが Java SE 8 では改善されています。また、ラムダ式でもメソッドパラメータの型についてはかなり推論が効くようになっています。
このセッションでは、Java SE 8 ではコンパイラのストラテジーをどのように変更することで改善を行ったかの説明がされていました。

型の推論はプログラムの記述から読み取れる変数の上限、下限境界の情報から連立不等式を組み立て、それを解くような感じになります。不等式が解けない場合は型の推論ができず、コンパイルエラーが起きます。
Java SE 8 ではこの式の組み立てや条件の与え方をより改善することで、これまでは NG だったメソッド引数での型パラメータの省略や、ジェネリックな返値の解決などができるようになっています。条件演算子を挟んでも推論が効くようになります。
このように Java8 では型推論がかなり改善されたため、ダイアモンド演算子が大概の場所で使えるようになるので、より複雑な API を設計可能になるとのことです。

What's New in Java Transaction Processing [BOF3433]

Java EE 7 に含まれる、JTA 1.2 についての解説です。JTA は実に 10 年振りの改訂となったそうです。

2 つの大きな仕様追加があり、1 つは @Transactional アノテーション、もう 1 つは @TransactionScoped アノテーション。どちらも CDI に関わるものです。
@Transactional アノテーションは EJB と深く結びついていた CMT を EJB から切り離すためのものです。CDI の管理対象 Bean にこのアノテーションを貼ることで、EJB の CMT と同じ機能が得られるようになります。サポートしているトランザクションタイプとか、デフォルトは実行時例外でロールバックし、チェック例外ではロールバックしないのも同じです。
@TransactionScoped アノテーションは CDI 管理対象 Bean のスコープを定めるもので、トランザクションの範囲内でコンテキストが維持されるというものです。

Java EE の持つ機能は元々 EJB と強く結びついていたものが多かったのですが、このトランザクションのようにどんどん EJB から機能を独立して使えるようにしている流れになっているように見受けられます。今後は EJB は元々の役割であった分散処理、非同期処理の専用コンポーネントに戻っていくことになるのでしょうね。

Lightning-Fast Access to Big Data

IBM の方による BOF でしたが、分散インメモリキャッシュの話でした。一般論的に話そうとはしていましたが、まあ IBM の製品の話だったのでつまんなかったです。
やはり「ビッグデータ」なる言葉に釣られるとネタであってもロクなことがないと強く感じましたw

JAX-RS and JSON Binding: Past, Present, and Future

Java EE 7 では JSON をパースするための JSON-P は入りましたが、JSON のデータを JavaBeans にバインドするための JSON-B は結局入りませんでした。
次の Java EE に向けて、JSON-B の仕様が検討されているところのようですが、現在検討されているアノテーションについて淡々と説明する内容でした。
現在、Java の JSON バインディングのライブラリとしては Jackson や Gson あたりが有名だと思いますが、どうも Jackson をベースにしたものになりそうです。ただ、それに MOXy の機能も入れてみたいと考えているようです。(JAX-RS の参照実装である Jersey は 2.x で MOXy を使うようになっていますしね)

*1:JavaFX2.x の時は時間が足りず、ドロップしたそうです。

*2:Martin Fowler の GUI Architectures が参考になります

*3:ただし、インジェクションポイントを示すアノテーションには JSR-330 で定められている @Inject アノテーションを使っています

JavaOne参加レポート (9/22) (作成中)

今回、USサンフランシスコで開催される本家JavaOneに初めて参加することになりました。
本家JavaOneの雰囲気はすごいです！
9/21から現地入りし、26までフルに参加します。1日ごとにエントリをまとめたいと思います。
ただ、JavaOneは朝速くから夜遅くまでびっちりセッションが入っていて、結構忙しいです。とりあえず期間中は歯抜けの状態でアップして、あとで追々追記していきます。

本日 (9/22) は初日で、キーノートセッションと、他にはコミュニティ関連のセッションが中心でした。キーノート以外はまあ肩慣らしといった感じで軽めの内容のものが中心でした。
自分が参加したセッションは次の通りです。

• Fifteen Years of the NetBeans IDE [UGF10366]
• NetBeans Power Tools with James and Kirk [UGF10336]
• Java Strategy and Technical Keynotes [KEY11050]
• Cool NetBeans Tips and Tricks for JavaFX Development [UGF10339]

コミュニティセッションは全てNetBeans関連のセッションに参加しました。

以下、簡単にレポートをまとめます。

Fifteen Years of the NetBeans IDE [UGF10366]

NetBeansのこれまでとこれからについてのセッションです。NetBeansは今年で誕生してから15年になるとのことです。
パネリストの中に何とJames Goslingさんがいらっしゃいました！

過去の歴史のお話しでは懐かしい2.xや3.x時代のスクリーンショットが出てきました。最近になって利用者やコントリビュートが大きく伸びているそうです。
NetBeansの歴史を振り返った後7.4の説明になり、その後Goslingさんの思い出話になりました。でも、ぼそぼそとしゃべるので良く聞こえない。(><)
MSを常に意識していたとか、NetBeans前のSunのIDE開発の失敗の話とか、Eclipseについて「あいつらマーケティングがうまいんだよなー」と評したりとかそんな話をしてました。
でも最近盛り上がっていて、それはとっても嬉しいとのことでした。

その後ベータテストプログラムのNetCATや、NetBeansのハイスキルなコントリビューターやユーザで構成したプロモーションチームであるNetBeans Dream Teamの紹介をして締めくくっていました。ちなみにNetCATの一番の貢献者には実際に会ったことがないと話してました。OSSらしいですねえ。

NetBeans Power Tools with James and Kirk [UGF10336]

こちらにもGoslingさんがスピーカーとして登場していました。もう一人のスピーカーはJava Performance Tuningで有名なKirk Paperdineさんです。
Goslingさんは所属しているLiquid Robotics社の海洋探査ロボットのデスクトップ版とWeb版コンソールの話、KirkさんはVisualVMによるメモリプロファイルの話をしました。はい、お2人の話の間には何の関連性もありませんw

Goslingさんの海洋探査ロボットのデスクトップ版コンソールですが、確か去年のJavaOneに登場したときのデモでは、「JavaFXを使っていなくてごめんねー」と言っていたように記憶していますが、最近JavaFXも使うようになったようです！WebViewを活用していて、ロボットの位置を地図上でトレースする様子を見せていました。
面白かったのはWeb版クライアントで、ロボットにEmbedded GlassFishが入っており、ブラウザから直接指令を送れるようになっていました。実際に今動いているロボットに対して、ブラウザから「右にターンしろ」と指令を出して、見事に向きを変え、デスクトップ版コンソールからも航路を変更している様子が見えました。

KirkさんはNetBeansのメモリプロファイルの機能の説明をデモを交えて行いました。実際にはNetBeansではなくJDKに付いてくるVisualVMですけど。なかなか高機能で、下手な商用アプリだと負けてしまいそうな感じですね。*1

Java Strategy and Technical Keynotes [KEY11050]

基調講演です。前半がストラテジーキーノートで、間にIBMのスポンサーキーノートが入って、その後にテクニカルキーノートを行うという流れでした。
今年はMosconeで行いましたが、雰囲気がすごいですね。まあAppleのキーノートとかには明らかに負けますが、でも講演の合間に歓声が飛んだりして、日本では考えられないような熱気でした。

ストラテジーキーノートで繰り返し強調されていたキーワードは "Internet of Things (IoT)" でした。日本語では「モノのインターネット」と訳されることが多いですが、これまでインターネットの利用は基本的に人間が介在していましたが、今後は様々なデバイスがインターネットにつながるため、デバイス同士が人間を介さずにインターネットを通じて連携する技術を指しています。M2M (machine to machine) と言う言葉もよく使われますね。
なので内容はかなりJava MEに重点が置かれていました (この部分を担当されていたのはJavaFXでもおなじみのNandini Ramaniさんでした) 。今までだとちょっと考えられないことでした。これまで組み込みJavaは様々なプロファイルが乱立し、Java SEとの乖離も大きかったのですが、今後はJava SEとMEの乖離を小さくする方向に持っていくことを繰り返し語ってしました。Java8EAもSE、ME両方リリースしています。このお陰でSEの開発者とMEの開発者のスキルセットが共有できるようになり、よりJava技術者の活躍の場が広がりますよ、とのことでしたw
ストラテジーキーノートの後半はEEの話でしたが、今年リリースしたJava EE 7の説明をした後に、何とAvatarのオープンソース化の発表がなされました！avatar.java.netにホストされています。サプライズという意味ではこれが一番大きなニュースだと思います。

(スポンサーキーノートの話は後で追記します)

テクニカルキーノートはさほど真新しい話はなかったのですが、構成がとても良かったです。
最初はMark ReinholdさんとBrian Goetzさんの掛け合いでのLambdaの解説。落ちは分かっていましたが掛け合いがとても面白い。
次にJavaEEの話。iPad上のSafariで動く対戦チェスゲームを紹介し、これはJavaEE7の新機能 (WebSocket、JSONハンドリング、バッチなど) を駆使して開発したHTML5アプリケーションである、そしてNetBeansを利用してクライアントとサーバーを通しての開発が可能であることをデモしていました。
続いてJavaFX。何やらごついタブレットを持ってRichard Bairさん、Jasper Pottsさんが登場しました。これはDukePadというRaspberry Piをベースに組み立てたお手製タブレットでした！ *2
このタブレット上で3Dのチェスゲームを稼働させ、先ほどのサーバーとWebSocketを通じてSafariのブラウザと対戦可能なことをデモしていました。Raspberry PiはCPUがとても貧弱ですが、GPUは強力で、GPUを有効活用するJavaFXなら3Dでも動かせることをアピールしていました。
さらにPC上で3DのDukeをチェスの駒にしたバージョンを披露。Dukeが歩いたり戦ったりと、よりゴージャスなできになっています。
そしてそこからさらに "One more?"。今度はチェスをするロボットです！これもやはりWebSocket経由でこれまでに出てきたチェスアプリケーションと対戦できます。
このように、チェスゲームという1つの軸を中心にして、モバイルブラウザ、スマートデバイス、デスクトップPC、そしてロボットと様々なクライアント、デバイスがインターネットとして通じること、そしてそれら全ての場面でJavaを使うことができる、というメッセージを伝えていました。前半のストラテジーキーノートともきちんとリンクした内容でしたね。
最後にちょっとJava9の話も出てきましたが、Unified TypeとJNI2というキーワードが気になりました。本当にできるのかどうかは分かりませんが...。

Cool NetBeans Tips and Tricks for JavaFX Development [UGF10339]

NetBeansプラットフォームとJavaFXを組み合わせた様々なアプリケーションを紹介するというセッションでした。
インパクトがあったのはNASA Mission Operationsです。太陽風と地球の磁気圏の干渉点の測定をするというミッションにおいて、そのデータを解析、視覚化するアプリケーションをNetBeansプラットフォームとJavaFXを組み合わせて作っていました。NetBeansプラットフォームはデータの管理アプリケーションを作るのに向いており、JavaFXは並列処理、DnDとクリップボードの扱いが優れているとのことでした。特に天体観測だとデータセットが非常に巨大になるのですが、並列処理を扱い易いというのは有り難かったようです。チャートコンポーネントも大量のデータ表示に耐えてくれたとのことでした。
その他にも様々なアプリケーションを紹介していましたが、どのアプリケーションもNetBeansプラットフォームを基盤としつつ、UXを強化したいところでJavaFXを食い込むという使い方をしていました。
セッションの最後にNetBeansのチームのメンバーに対して「NetBeansをJavaFXベースにする予定は？」という質問が飛んでいましたが、当面は考えてないとのことです。ただ、SwingとJavaFXのスレッド統合が組み込まれたら、どんどんJavaFXを取り込んでいくことになるだろうとの事でした。

*1:そういやOptimizeItもJProbeも見かけなくなったなあ

*2:紹介したリンク先でどうやって作ったかを解説しています

Java Day Tokyoに参加＆発表してきました

5/14 (火) に開催されたJava Day Tokyoに参加し、さらにその中のセッションの1つである、Java The Nightに登壇しました。
まさかこんな大きなイベントで自分が発表する側に立つことになるとは思わず、とても緊張しましたが良い経験になりました。
このエントリではイベントの感想についてまとめたいと思います。

Java The Nightでの発表について

Java The Nightで自分は「監視ツールでみるJavaFXとJava EEの魅力」と題して発表しました。セッション資料はSlideShareにアップしています。

Java Day Tokyo 2013 Java the Night 監視ツールでみるJavaFXとJava EEの魅力 from Takashi Aoe

登壇することになった経緯ですが、Oracle寺田さんからTwitterのダイレクトメッセージで突如お願いされましたw
寺田さんからの要望は、「デモの際におもしろ、おかしく、やっていただくことはできますでしょうか。」でした。
随分ハードル高いなあと思いつつも、折角の機会なので登壇させて頂くことになりました。

発表の内容としては、JavaFXで作ったGlassFishの監視アプリケーションのデモを通して、自分がJavaFXやJava EEの魅力と思っている点について伝えるというものでした。
インパクト重視という要望だったので、JavaFXで作るアプリは派手めな、中二病っぽい感じの路線で行くことにしました。

JavaFXについてここで伝えたかったことは、プログラムを使って何かやりたいタスクがあったときに、JavaならばJavaFXが加わったことで、このように綺麗なGUIで成果をアウトプットできるようになるということです。
CUIもいいけど、GUIでやると楽しいですよ。
このアプリケーションのルックスについては予想以上に反響があったようですが、実はそんなに手数を掛けなくてもこのような見た目にすることが可能です。この点については後ほど別エントリで解説します。

Java EEについては、運用フェーズにおける監視という側面からの利点を伝えようとしました。Java EE APサーバーはいずれもサーバー上で稼働するサービス、アプリケーションに対して豊富な監視オプションを提供しています。
Webアプリケーションフレームワークはともすると開発の側面ばかりに目が行きがちですが、ソフトウェアのライフサイクル全体で考えると運用も重要です。その点も考慮して選択を考えてもらったらと思います。

各セッションについての感想

それでは自分が参加した各セッションについて軽く感想を書いていきます。

基調講演

基調講演ではJava SE、Java FX/Embedded、Java EE、コミュニティについて、それぞれのOracleのキーパーソンから現状と今後の展望について説明するというものでした。
特に自分の印象に残ったのが、OracleがM2Mを重視しているように見えたことです。今後は様々なデバイスがネットワークでつながるようになるため、確かに次にソフトウェア開発の分野でホットになるのはここかも知れません。そして恐らくこの分野でもライバルになるのはAndroidでしょうね...。

Raspberry Pi NightHacking

Pro JavaFX 2の著者の一人であるStephen Chinさんによる、Raspberry Pi上でのJavaFXアプリケーションの実行についてのセッションでした。
目の前でJavaFXアプリケーションを構築して、それをRaspberry Piに移植動かすところまでを見せてもらいました。
驚いたのは、本当にそのままのJavaFXアプリケーションが動いているということです。エフェクトとかも普通に動いていました。質問したところ、動かないのはWebViewとMediaViewだけとのことです。
Raspberry Pi向けのJava SEのプロファイルは結構小さいのですが、それでもJavaFXアプリケーションがここまで動くというのには色んな可能性を感じさせてもらいました。

Java IDE の最新トレンド

Eclipse、NetBeans、IntelliJ IDEAというJava界三大IDEについて、Eclipse派代表として竹添さん、NetBeans派代表としてきしださん、IntelliJ派代表として今井さんが語り合うというとても楽しいセッションです。
モデレータの山本裕介さんがIntelliJユーザーと言うこともあり、ややIntelliJにバイアスが掛かっていたような気がしましたが。(^^;;
スライドが三者三様でこちらもそれぞれの個性が出ていて面白かったです。竹添さんはきっちりPowerPointで、今井さんはrstテキストで、そしてきしださんは安定の手書き資料w
なお、自分は基本的にNetBeans派ですが、IntelliJもちょこちょこ触りますし *1 、もちろん仕事の必要上Eclipseも結構触ります。
ディスカッションで自分の印象に残ったのは以下の点です。

• Eclispeは確かにセッティングが面倒だけど、Eclipseが出たての頃はみんなその作業をとても楽しんでいた。
  • 確かに自分もEclipseが登場したての頃は、とてもわくわくしながら拡張を楽しんでいたのを覚えています。
• InteillJはJava、Groovy、Scalaを1つのプロジェクトに混在させて開発できる。
• NetBeansはJenkins連携ができる。ただしメニュー名は "Hudson" だけどw
• (テキストエディタ派の人に向けて) IDEの利点は「IDEが良い書き方を教えてくれる」ところにありますよ。

Groovy, Clojure, Scala, VisageでのJavaFX活用

こちらもStephen Chinさんによるセッションです。Groovy、Clojure、Scala、Visage *2 、JRubyでのJavaFXのサポート状況について順に説明してもらいました。
ちなみにChinさんはScalaFXとVisageのコミッタをされています。
JavaFXのサンプルアプリケーションとしてよく使われる、Vanishing Circleを例に、他の言語で実装した例を見せてもらいました。

特に自分がいいなと思ったのがGroovyFXです。@FXBindableアノテーションを付けることで、JavaFX形式のプロパティを生成してくれるのはとても嬉しい！
自分の以前のエントリでも解説しましたが、JavaFX形式のプロパティの記述はちょっと面倒なのです。
ScalaFXもとてもScalaらしいアプローチでDSLを設計していて、こちらも好感が持てました。
VisageはJavaFX Script時代から言語仕様が強化されているのですね。

なお、Chinさんは日本の漫画やアニメが相当好きなようで、各言語についてアニメに例えてらっしゃいました。以下の通りですが自分のよく知らないモノもあるw

• Groovyはルパン三世
• Clojureはワンパンマン
• Scalaはグレンラガン
• Visageはエヴァ
• JRubyはブリーチ

タブレット用の JavaFX アプリケーション開発

JavaFXエヴァンジェリストであり、Pro JavaFX2の著者の一人である、Jim Weaverさん *3 による、JavaFXのマルチタッチ関連APIの解説と、タブレット向けアプリケーションを作る上での注意点について説明するというものでした。
タブレットのターゲットはWindows8でした。実際にSurface Proを操作しながら解説していました。

マルチタッチ関連APIの解説の内容は自分が先日JavaFX勉強会で行ったものとほぼ同内容でしたw
タブレット向けアプリケーションを開発する上での注意点は、やはりコントロールの大きさでした。そのためにデザインにはなるべくCSSを活用し、まずはrootクラスのフォントを32px程度にするのが良いとのことでした。

結構説明が早く終わってしまったので、質問がいっぱい出ていました。自分は高解像度端末におけるスケーリングの対応について聞いたのですが、現時点では端末に合わせて自分でサイズを調整するしかないようです。でも、後で気付いたのですが、確かJavaFX8で導入されるModenaテーマはスケーリングの変化に対応していたような？

Java The Night

最後は自分も登壇したJava The Nightです。みなさん実に色んな持ちネタを披露してもらって、とても楽しめました。
驚いたのはほとんどの人がJavaFXを使っていたことです！自分が考えている以上にJavaFXがJava開発者の間で認知度を上げているのかも知れません。

最後に寺田さんから発表されたJava7のAPIドキュメント日本語化のニュースは驚きました。Oracle本体を説得して日本語化にこぎつけた日本Oracleの皆様方には感謝です！

このように、聴講、発表共にとても楽しい一日を過ごすことができました。このような素晴らしい場を提供して頂いた日本Oracleの皆様には厚く御礼申し上げます。ありがとうございました。

*1:特にJavaFXサポートが入ってからは、JavaFXサポート機能がなかなか強力なので結構触るようになりました。

*2:OracleがディスコンにしてしまったJavaFX Scriptをオープンソース化したものです

*3:ちなみに先日のJJUG CCCでは櫻庭さんのお誘いで、Jimさんとお昼ご飯を食べに行きました。

JDK7でJDBC接続の切断のためのAPIが追加されていました

昨日アップした以下のエントリのフォローアップです。

JDBCのStatement#cancelは即座の中断を期待してはいけないみたい
http://d.hatena.ne.jp/aoe-tk/20121112/1352729379

JDK7 (JDBC4.1) では、 java.sql.Connection に、JDBC接続を強制的に切断するための abort というメソッドが追加されていました。

MySQLのバグトラックのこのチケットでもこのメソッドについて説明されています。

This is precisely the reason the JDBC-4.0 spec added the abort() method. There is no foolproof way to implement the semantics of Connection.close() *and* never have deadlocks.

The abort() method is designed to be used in these cases (it takes no locks, but doesn't attempt to clean up currently open statements, etc).

しかし今のお仕事ではまだJDK7に正式対応していない某黄色い象さんが関わっているので使えないんですよねえ。*1

*1:で、そのことをぼやいていたら、某C社の方々にこんなことやこんなことを言われてしまったのですが。(^^;)

JDBCのStatement#cancelは即座の中断を期待してはいけないみたい

今日ちょっと気付いたことなのでメモ。

JDBCの処理を行っていて、別スレッドから中断を行う仕組みを実装しようと思い、JDBCの Statement#cancel() を使ってキャンセルする処理を実装してみました。
ところが、MySQLで試したところ、ロック待機を行っている UPDATE 文を実行している Statement に対して cancel() を実行したところ、ちっとも中断されず、ロックタイムアウトが起きるまでそのままでした。

何でだろうと思って調べてみたら、MySQLのバグトラッカにこんなチケットが上がっているのを見つけました。

JDBC statement.cancel() needs to actually cancel the current query
http://bugs.mysql.com/bug.php?id=36332

このチケットは "Not a Bug" として閉じられています。コメントの中に次のような記述がありました。

The issue as I see it is that the JDBC specification requires that cancel() (or statement timeout expiring) leaves the connection in a useful state. Therefore, the JDBC driver needs to use a mechanism that doesn't clobber the *network* side of the connection.

Therefore, we use "KILL QUERY" (on MySQL-5.0), which does have the interesting properties that it doesn't always return immediately, and sometimes one can wait a *long* time for the cancel, as SELECTs only check if they're killed in very specific places.

JDBCの仕様では、Statement#cancel() は実行後にコネクションがちゃんと使える状態で復帰するように実装することを求めているとのことです。
で、MySQLでは KILL QUERY を使ってこの処理を実装していますが、これはMySQLのマニュアルの記述によると、UPDATE や DELETE 操作の場合、各ブロックの読み込みや、行の各更新や削除の後でキルフラグを確認するため、場合によってはずっと待たされてしまうようです。

JDBCが安全な復帰を求めている以上、Statement#cancel() で無茶な中断はできないでしょうから、このように即座の中断を求めることは難しそうです。(先のMySQLのバグトラッカのコメントにも「JDBC EGに強制キャンセルの仕様をリクエストするしかないね」とありました)

強引な強制中断をしたければタイムアウトを併用するか、コネクションごと切っちゃうしかなさそうですね。

謎なMacのJavaインストール構成

先日、ようやくMac版JDK7のGA版が登場しました。今までMacのJDKはAppleが提供していましたが、7からはOracleからの提供となります。
早速インストールしたのですが、実に奇妙な現象が見られたのでここに記録しておきます。

インストールはOracleのダウンロードサイトからダウンロードしたインストーラを使ってインストールします。特に難しいことはなく、指示に従ってインストールするだけです。

インストール後、JDK7をデフォルトのJDKにするには設定変更が必要です。ここで説明されているのですが、/Applications/Utilities/Java Preferences.app を起動し、以下のスクリーンショットのように [Java SE7] をドラッグして一番上に持って行きます。

これでJDK7がデフォルトで有効になるはず、なのですが自分の環境ではそうなりませんでした...。

$ java -version
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)

その時は一旦あきらめたのですが、後日、ふと .bash_profile に環境変数 JAVA_HOME を設定しており、そこで JDK6 のインストールパスを指定していたことを思い出しました。そこで、JAVA_HOME の設定を削除して、シェルを再度開いて確認してみると...

$ java -version
java version "1.7.0_04"
Java(TM) SE Runtime Environment (build 1.7.0_04-b21)
Java HotSpot(TM) 64-Bit Server VM (build 23.0-b21, mixed mode)

ちゃんとJDK7を認識しています！ これで晴れて自分のMac環境もJDK7環境になりました。

しかし疑問が残ります。JAVA_HOME は設定していましたが、パスはそこには通していませんでした。実際、環境変数を変更した前後で "which java" をしても /usr/bin/java を指しています。
まず、/usr/bin/java の実体を調べてみます。

$ ls -li /usr/bin/java
40738383 lrwxr-xr-x  1 root  wheel  74  4 15 20:59 /usr/bin/java -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java

/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java にシンボリックリンクが貼られています。
で、パスの途中に出てくる "Current" というディレクトリですが、以下のように "A" というディレクトリに対するシンボリックリンクとなっています。

$ ls -li
total 64
40738298 lrwxr-xr-x  1 root  wheel   10  4 15 20:59 1.4 -> CurrentJDK
40738299 lrwxr-xr-x  1 root  wheel   10  4 15 20:59 1.4.2 -> CurrentJDK
40738300 lrwxr-xr-x  1 root  wheel   10  4 15 20:59 1.5 -> CurrentJDK
40738301 lrwxr-xr-x  1 root  wheel   10  4 15 20:59 1.5.0 -> CurrentJDK
40738302 lrwxr-xr-x  1 root  wheel   10  4 15 20:59 1.6 -> CurrentJDK
40738303 lrwxr-xr-x  1 root  wheel   10  4 15 20:59 1.6.0 -> CurrentJDK
24547503 drwxr-xr-x  8 root  wheel  272  4 15 21:56 A
40739474 lrwxr-xr-x  1 root  wheel    1  4 15 20:59 Current -> A
40738356 lrwxr-xr-x  1 root  wheel   59  4 15 20:59 CurrentJDK -> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents

この A という名前のディレクトリですが、Mac上にフレームワーク環境を構築する際には、複数のバージョンを入れておきたい場合は、A, B, C... というアルファベット順のディレクトリを作って、そこに異なるバージョンを入れるようにするという慣習になっているようです (Appleの解説はここ) 。
で、A/Commands の中を覗いてみると次のようになっていました。

$ ls -li A/Commands
total 1280
40738305 -rwxr-xr-x  1 root  wheel  54272  4 15 20:59 appletviewer
40738306 -rwxr-xr-x  1 root  wheel  54272  4 15 20:59 apt
40738307 -rwxr-xr-x  1 root  wheel  54272  4 15 20:59 extcheck
40738308 -rwxr-xr-x  1 root  wheel  54272  4 15 20:59 idlj
40738309 -rwxr-xr-x  1 root  wheel  54272  4 15 20:59 jar
40738310 -rwxr-xr-x  1 root  wheel  54272  4 15 20:59 jarsigner
40738311 -rwxr-xr-x  1 root  wheel  54272  4 15 20:59 java
40738312 -rwxr-xr-x  1 root  wheel  67456  4 15 20:59 java_home
...

リンクではなく、実ファイルのようです。もしかしてハードリンクなのかな？と思ったのですが、JDK7のコマンドディレクトリに入っている java を確認してみると...

$ ls -li /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home/bin
total 6888
41515326 -rwxrwxr-x  1 root  wheel  88864  4 20 14:58 appletviewer
41515327 -rwxrwxr-x  1 root  wheel  88864  4 20 14:58 apt
41515328 -rwxrwxr-x  1 root  wheel  88864  4 20 14:58 extcheck
41515329 -rwxrwxr-x  1 root  wheel  88864  4 20 14:58 idlj
41515330 -rwxrwxr-x  1 root  wheel  88864  4 20 14:58 jar
41515331 -rwxrwxr-x  1 root  wheel  88864  4 20 14:58 jarsigner
41515332 -rwxrwxr-x  1 root  wheel  88800  4 20 14:58 java
41515333 -rwxrwxr-x  1 root  wheel  88864  4 20 14:58 javac
...

実体が違うようですし、何よりファイルサイズもタイムスタンプも異なります！ JDK7の同名ファイルより古いですし。
そして、環境変数 JAVA_HOME の設定を戻して、JDK6を指すようにしてから、A/Commands の下を見てみると...

$ java -version
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635)
Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)
$ which java
/usr/bin/java
$ ls -li /System/Library/Frameworks/JavaVM.framework/Versions/A/Commands
total 1280
...
40738311 -rwxr-xr-x  1 root  wheel  54272  4 15 20:59 java
...

全く変わっていないんですけど...。
ということは、これは推測なのですが /System/Library/Frameworks/JavaVM.framework/Versions/Commands 以下に入っているコマンドは全てプロキシで、呼び出されたら現在のデフォルトバージョンとして指定されているJavaのディレクトリにある同名のコマンドを呼ぶようになっているということでしょうか？
で、その呼び出し先を指定するのが Java Preferences.app の設定であり、環境変数 JAVA_HOME が設定されている場合はさらにそれを優先させる...と言った所ですかねえ。

以下のAppleの開発者向けドキュメントを読んでみたのですがイマイチ要領を得ません。
http://developer.apple.com/library/mac/#qa/qa1170/_index.html
http://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/00-Intro/JavaDevelopment.html

どなたかこのあたりの事情に詳しい人いますか？

追伸

MacのJDK7にはJavaFX2.1のSDKが同梱されています。JDK7をデフォルトに設定すると、JavaFXアプリケーションのJARをFinderでダブルクリックするだけで起動できるようになります。
また、NetBean7.1.2をインストールすると、特別な設定なしでJavaFXの開発もできるようになります。

JavaOne Tokyo 2012参加レポート (2日目)

JavaOne Tokyoの2日目のレポートです。色々忙しくって随分遅れてしまいました。すみません...。

2日目は次のようなセッションに参加してきました。

• Technology Keynote
• The Java EE 6 Programming Model Explained
• Project Jigsaw: Putting it all Together
• How to Write Low Latency Java Applications
• ForgeとArquillianを利用したJava EEアプリケーションの迅速な開発
• UI Controls and Charts: Drag-and-Drop, Filtering, Sorting, Table Hookup with Charts
• Learn how the JVM is fundamental to our architecture.

Technology Keynote

Technology KeynoteについてはやはりSFの内容をなぞったものでした。その後、スポンサー講演として富士通の方の講演がありましたが、こちらは昨日のNECさんの様子を見たせいか、スーツスーツしないような内容に気を遣ってものとなっていましたねー。

Technology Keynoteの内容では次のようなことが気になりました。

• JavaFXの所では、開発環境の分断 (iOS、Android、Windows、Linuxなど全て別々の開発環境が必要となる) を強調しており、JavaFXは1つのAPIで全てのプラットフォーム向けに開発できるようにすることを目指しているという話が印象的でした。縮小気味と言わざるを得ないAdobe AIRに代わってクロスプラットフォームのGUI開発環境の地位を目指しているのだと捉えました。
• JavaFXのサンプルであるEnsembleはBSDライセンスでオープンソースなのだそうです。また、Oracleのここのページで、Henley Sales Dashboardというデモアプリケーションが紹介されているのですが、このアプリケーションがGlassFishに構築したサーバーアプリケーションとJerseyのクライアントAPIを使って通信しているとのことでした。
• JavaEEの話も既にあちこちでされている話ばかりでしたが、バッチが入るという話があり、これには驚きました。どんな感じになるんだろう？
• JavaMEではOJWCの話が目を引きました。次世代フィーチャーフォン向けのランタイムとのことです*1。フィーチャーフォンにもリッチなUIを構築できるようなツールキット (LWUIT) を提供したりするそうです。確かにスマートフォンばかりに注目が移りますが、途上国を中心にフィーチャーフォンへの需要もまだまだ大きいはずで、そこをターゲットとしているのでしょうかねえ。そうなるとライバルはやはりAndroidとなりますが...。

最後の富士通さんの講演ですが、やはり前日の雰囲気を見ていたのか、ちょっとおっかなびっくりな感じで話されていたような。(^^;)
初音ミクの話をしたり、チェスのプログラムを趣味で作った話をしたりと、余り堅くならないように気を遣って話をされていたので、前日のよりは好意的に受け入れられていたように思われます。
Interstage on Azureの話や、Hadoopの独自ファイルシステムの話が出てきて、これはとても気になったのですが、さらっと流されてしまったのが残念。

The Java EE 6 Programming Model Explained

標題通り、JavaEE6のプログラミングモデル全般のお話しでした。中国訛りの英語を話される方だったので、少し聞き取りにくく、同時通訳の力を借りることになりました。
内容的には既に知っていることも多かったのですが、次のような内容が印象に残りました。

• パッケージングについて、実はJavaScriptのリソースとかもJARに固めることができる。
• コンテナがどんなPOJOも管理できるようになり、それがManagedBean。実はEJBもManagedBeanの一種。
  • これはインクリメンタルなプログラミングモデルをサポートしていると言うこと。例えば、最初はManagedBeanで作り始めて、途中からEJBのTx管理の機能とか欲しくなったらアノテーションを付け替えてEJBに昇進させることが可能になる。
• CDIは最も進んだDIフレームワークだ！
• 柔軟な拡張機能を利用してより強力に (ペガサスの絵を出してました)。ServletとCDIが拡張可能。Servletだとコンテナの初期化時に処理を噛ますようなこととかができる。

正直に白状すると、実は裏番組であるJavaFXのセッションの内容がずっと気になっていました。
TwitterのTLを見ていると、ライブコーディングで作成したJavaFXアプリケーションをiPadに載せて動かすデモをやっている様子の実況が流れてきていました。すごい見たかった...。

Project Jigsaw: Putting it all Together

Lambdaと共にJava8に導入予定のJigsawのお話しです。実はこれまでJigsawについてはきちんと調べていなかったので、このセッションを聞いて結構衝撃を受けました。実はLambdaよりも遙かに大きな変革のように思われます。

Project Jigsawは一言で言うとこれまでのJARを使ったJavaのパッケージングの仕組みを根底から見直そうというものです。
JARを使ったパッケージングには色々問題があります。依存性の指定ができないし、バージョニングもできないので、このあたりMavenさんの力を借りて何とかしてきたのが実情です。
そこで、新たにモジュール宣言の仕組みを導入して、これらの問題を解消することを目指すようです。

module-info.javaにモジュールの内容を宣言するのが基本になります。ここで自分のモジュールの定義やバージョン、依存性といったものを記述します。外部に公開する範囲の指定とかも可能になります。
パッケージングはjmodファイルという単位でパッケージすることになり、これはdebとかrpmとかに相当するものです。また、ネイティブパッケージ自体にも対応して、debとかにコンバートができるようにするとのことです。

また、これによりJDK自体もモジュール化して、desktopとかheadlessとかのくくりに整理するようになるそうです。これで、本当に必要なモジュールだけダウンロードして、ラインタイムをスリム化することが可能になるということでしょうね。組み込みではこれは重要ですねえ。iOSとかだと規約の関係上、JREごとアプリにぶち込む必要がありますし...。

このような感じで実に大きな変化だと思いました。自分的にはこの変化の大きさはLambdaの比じゃないです。
ネイティブのパッケージもサポートするというのは面白いですね。特にデスクトップJavaに効いてくると思います。デスクトップJavaアプリケーションをOSのパッケージャー経由でインストール、アップデートできるようになるというのは大きいと思います。

How to Write Low Latency Java Applications

低レイテンシなアプリケーションを作るためには何を知り、どう作る必要があるのかを詳しく説明してもらいました。とても面白かったです。
アプリケーションが低レイテンシになるようにチューニングするには、まずJVMの仕組みの部分を知った上で、測定が重要です。
知るべき仕組みとしてGCとJITの解説を、最後に測定を支援するツールの話をしてもらいました。

GCについては、世代別管理の説明をした上で、その特徴を踏まえた上でコーディング上で注意すべきことの解説を行っていました。

• オブジェクトアロケーションよりもオブジェクトの保持の方がレイテンシに影響する。
  • GCはライブオブジェクトのみ触り、ライブオブジェクトの数とオブジェクトグラフの複雑さがその時間に影響を与える。
• オブジェクトアロケーションは低コストなのでオブジェクト生成を怖がらなくても良いよ。
  • とは言え、無駄にアロケーションするとマイナーGCの頻度が上がり、結果としてオブジェクトのOld行きが早まる可能性が出てくる。
• 小さくてイミュータブルで短命なオブジェクトがGCは好き！
• 理想的にはOld領域のGCを発生させないようにする。その上でマイナーGCが一番早いParallelGCを選択する。
  • OldGCが発生してしまうのなら、Concurrent Mark and Sweepが良い。
• ラージオブジェクトはアロケートが高コストだしヒープのフラグメンテーションを招くので避ける。少なくとも定常的にアロケートしない。
• 配列を使ってコンテナオブジェクトのリサイズは避ける。余計なオブジェクトのアロケーションを発生させるので。コンストラクタで明示的にサイズを指定する。
• オブジェクトプールも良くない。GCはライブオブジェクトをたどるので負担が上がる。
• ファイナライザ絶対に使うな！最低でも2GCサイクルを使う。ちゃんと明示的にリソースを解放するメソッドを自分で用意すること。
• innerクラスも外のクラスの参照を持っているので注意が必要。

次にJITについての解説があり、一番効果が大きいのはメソッドのインライン化。で、そのために注意すべき点として次のようなものを挙げていました。

• 抽象メソッドはインライン化の障害になることがある。
  • 実装が1つしか見つからないときは抽象化を解くけど、新たに実装が見つかったら最適化していたのを戻しちゃう。
  • 抽象メソッドの追加実装の探索はスローダウンを招く可能性が。
  • 巨大なポリモーフィック呼び出しはインライン化の機会を奪ってしまう可能性がある。
• とは言え、気にしすぎても仕方が無いので最も自然なフォームで書くようにすればいいよ。ほとんどのケースでよしなにやってくれるし。(^^;)

最後に計測を支援するツールとして、JRockitのツール類やGC Histo、Solaris Studioのアナライザなどを紹介していました。とにかく計測が大事だと何度も繰り返していました。

とても勉強になりました。ただ、低レイテンシを重視する場合にはここに挙げたことを考慮する必要がありますが、レイテンシだけが重要とは限らないことには注意が必要でしょうね。レイテンシよりもスループットの方が大事な場面も多いですし。

ForgeとArquillianを利用したJava EEアプリケーションの迅速な開発

JBossの方の発表でした。前半はJavaEE6のプログラミングモデルの解説、後半はJBoss Forgeの解説でした。何とArquillianの話はここではありませんでした。別のセッションでその話をするので、そっちで聞いてねーということで。Arquillianの話の方を楽しみにしてたのに...。

JavaEE6の解説については、他のセッションと内容がかなり被っていました。
CDIのDeltaSpikeの話は興味深かったですね。これはベンダーニュートラル (Seam3 + CODI + CDISource) なCDI拡張機能を提供するというオープンソースのプロジェクトです。こういうのが出てくるということは、CDIも徐々に浸透してきているということでしょうか。
あと、JavaEEサーバーはもう重くないよ、みんな秒単位で起動するよ、の話も印象に残っています。

後半はJBoss Forgeをライブデモを交えて紹介していました。これはSeamにあった、Seam Genの進化形のようですね。
要はRailsやSpring Rooのように、コマンドラインで対話式にアプリケーションの構成要素を追加していけるというツールです。
まあ、この手のツールにある機能を一通り備えているな、という感じでした。ライブラリを色々選べるのがよさげでした。

UI Controls and Charts: Drag-and-Drop, Filtering, Sorting, Table Hookup with Charts

申し込んだ時点ではJPAのセッションに申し込んでいたのですが、それはパスしてこちらの方にキャンセル待ちで入りました。
JavaFXで提供されているコンポーネント類の解説と、JavaFX2.1の新機能の解説もありました。
解説をされたのはFX Experienceによく記事を書かれているJonathan Gileさんだったのですが、めちゃめちゃ早口で、すごいペースで飛ばしたので、かなり時間が余り、QAでいっぱい質問が飛んでいました。

まずはJavaFXで用意されているUIコントロール類を一通り、ざっと紹介していました。でも、JavaDocレベルの解説をざーっとされるよりも、いくつかにポイントを絞って深く説明をして欲しかったですね。特にListやTableコンポーネントで必要となるCellFactoryやCellValueFactoryの話は詳しくすべきだったと思います。なじみのない人には難しい概念なので。

続いて2.1の新機能の話ですが、一番驚いたのはMacのシステムメニューバー対応の話でした。これは当分無いだろうと思っていたのに、こんなに早いタイミングで対応が来たので面食らいました。
というか、個人的にはこれに対応するくらいなら他に対応することいっぱいあるだろー、と思ったのですが、まあ、熱心な林檎信者にとってはとても重要なことですからねえ...。*2

時間が余ったのでQAでは質問がいっぱい飛んできました。大抵は「○○はありますか？」という質問に、「まだ無いんです。JIRAでリクエストあげてね」という回答だったのですがw 欲しいものがあればどんどんアピールしよう、とのことでした。
自分はMacのシステムメニューバーについて質問しました。というのも、JavaFXではSwingとメニューの扱いが異なるからです。Swingの場合、メニューはコンテンツ区画とは別になっていていますが (ここの解説を参照) 、JavaFXの場合はMenuはシーングラフ上に載ります。なので、Macでシステムメニュー化した場合にどう扱われるのかが気になりました。で、答えは「Macのシステムメニューに設定した場合は、Menuはシーングラフから抜けてしまう」とのことでした。なのでWindows、Mac両方で稼働させる場合にはレイアウトに注意が必要ですね。

Learn how the JVM is fundamental to our architecture.

TwitterのRob Bensonさんによる、Twitterのシステムの中で中核とも言えるタイムラインを捌くシステムについての解説です。
化け物級の大量メッセージを遅延無く処理するためにどのようなアーキテクチャになっているのか、結構突っ込んでお話ししてもらったように思います。めちゃめちゃ面白かったです！

Twitterはとんでもない量のツイートが日々サーバーに飛んできています。しかも世界のどこかで何かイベントがあるととんでもなくスパイクします。バルスとかバルスかバルスとかwww
そういうのに耐え、リアルインフォメーションを提供するためのプラットフォームを作ることがTwitterの目標だとのことです。

そのTwitterのアーキテクチャですが、一番下のストレージから、モデル、コンポジション、ルーティングの4層構造になっており、また、それぞれのレイヤもユーザーやツイート、タイムラインなどのサービスに応じたモジュールに分かれているようです。最初このあたりはRailsを使ったモノリシックな構造になっていたのが、RubyではどうしてもGCやスレッドモデルに限界があったため、少しずつJVMに置き換えていったとのことです。
Twitterはすさまじい同時接続と大量のI/Oが発生しますが、データの永続処理はそれに比べると少ないという特長があるそうです。なのでサーバーのワークロード管理が重要であると。
Javaは最高レベルのJITと成熟したコンカレンシーモデルを持ち、Web層で採用しているNettyのようなプロダクトも豊富であるところが良い点であると評価していました。ただ、GCなどメモリ管理部分については改善の余地が有り、OpenJDKに参加して作業するようになったということだそうです。

続いて中核となるFinagleについての解説に入りました。これは関数型、非同期のRPCサーバーで、分散型サーバーに求められている接続プールやリトライと言った機能も備えているとのことです。GitHub上でOSSとして公開しています。中間レイヤのサービスの類はみんなこれが見ているそうです。

そしてこれがタイムラインをどのように捌いているかの説明になりました。タイムラインはツイートIDの時系列リストで、140Mのアクティブユーザー、秒間200Kのクエリが発生するというくらくらするような世界です。そんな中でクエリのレイテンシはピーク99%で4msに押さえているとのこと！
ツイートを行うと、フォロワーのタイムラインに対してメッセージをファンアウトするようになっていますが、レディー・ガガになるとそれが2000万を超えたりします。これをリアルタイムで配信する必要があります。全体で1分あたり1800万のツイート配信を行っているそうですが、それでも配信のレイテンシは3.5秒程度に押さえている。...すごい話です。

クライアントからツイートが送られてくると、プロキシが受けてAPI経由でキューに投入します。この時点でクライアントに応答を返すようです。それをツイートデーモンに渡してファンアウトしていきますが、フォロワーが多い場合は4000ごとに配信サービスに渡しているようです。配信されたツイートはタイムラインキャッシュと呼ばれるキャッシュに入ります。タイムラインのデータは99%インメモリで処理しているとのことです (Redisを使っているとのこと)。
タイムラインの読み込みについては、タイムラインを担当するサービスを経由して先述のキャッシュから読み込んできます。キャッシュ上のタイムラインのデータはパーティショニングを行っているようです。
こんな感じで役割に応じたサービス間を渡り歩いて処理をしていきますが、これら全てのサービスの中核としてFinagleがあり、ルーティングを行っています。データはThriftでやりとりしているとのことです。

こんな調子でとっても中身の濃い話を時間いっぱいして頂き、分散処理アーキテクチャについてのとても良い勉強になりました。とっても楽しかったです。

スペシャルセッション

2日目のスペシャルセッションはコミュニティ活動についてのパネルディスカッションでした。
最後だったということもあって、割とまったりとした感じでコミュニティ活動の意義について語り合っていました。

打ち上げ

最後にJJUG主催の打ち上げにも参加してきました。普段Twitterでしかやりとりしていない人達ともご挨拶ができて良かったです。
そして何と言っても最後の寺田さんの胴上げ！ 寺田さんは日本のJava界のOracleに対する不満を正面から受け止め、少しでも良くするために奔走されていたと思います。ホントに良い仕事していました。

忙しい中2日も空けての参加でしたが、参加してとっても良かったです。様々な刺激を受け、色んなことを吸収できたと思います！
最後に1日目に続いて当日のTwilogのリンクを貼っておきます。やはり大半がJavaOneについてです。
http://twilog.org/aoetk/date-120405

*1:NokiaのS40やS60あたりに組み込むのかな？

*2:大画面化した今の時代ではあのメニューは使いにくいだけだと思っているのですが、そんなことを思ってしまう私はMacユーザー失格なんでしょうか (^^;)