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の一種。
- 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を発生させないようにする。その上でマイナーGCが一番早いParallelGCを選択する。
- OldGCが発生してしまうのなら、Concurrent Mark and Sweepが良い。
- ラージオブジェクトはアロケートが高コストだしヒープのフラグメンテーションを招くので避ける。少なくとも定常的にアロケートしない。
- 配列を使ってコンテナオブジェクトのリサイズは避ける。余計なオブジェクトのアロケーションを発生させるので。コンストラクタで明示的にサイズを指定する。
- オブジェクトプールも良くない。GCはライブオブジェクトをたどるので負担が上がる。
- ファイナライザ絶対に使うな！最低でも2GCサイクルを使う。ちゃんと明示的にリソースを解放するメソッドを自分で用意すること。
- innerクラスも外のクラスの参照を持っているので注意が必要。
次にJITについての解説があり、一番効果が大きいのはメソッドのインライン化。で、そのために注意すべき点として次のようなものを挙げていました。
- 抽象メソッドはインライン化の障害になることがある。
- とは言え、気にしすぎても仕方が無いので最も自然なフォームで書くようにすればいいよ。ほとんどのケースでよしなにやってくれるし。(^^;)
最後に計測を支援するツールとして、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
