後半戦スタートです。
だんだんと疲れてきて、今日は朝起きられませんでした。なので、朝ご飯は抜き ><
さて、今日聴講したセッションです。
- TUT6825 Project Jigsaw Hack Session
- CON6712 Enhanced Process APIs
- CON5107 Prepare for JDK 9
- CON3523 JSR 377: What's Up and What's Next
- CON1868 Shenandoah: An Ultralow-Pause-Time Garbage Collector for OpenJDK
- BOF7768 Visualize Log Files for Troubleshooting Java Applications
今日はいろいろと失敗続き。
まず、Jigsaw の Hack Session がチュートリアルなのに、実質 Q&A セッションだったこと。質問できるレベルじゃないんだから、ちゃんとしたチュートリアルにしてほしかった....
次にランチ食べに行っていたら、聞きたいセッションに間に合わなかったこと。Unsafe に関するセッションを聞きたかったんだけど、満員で部屋に入れませんでした。しかも、Java SE 10 に関する話もあったらしい。
今年の JavaOne は Java SE 10 のセッションがぜんぜんないので、Java SE 10 に関する話、特に Project Valhala に関する話題は貴重だったのに....
そして、JSR 377 のセッションで、JSR 377 がまったく進んでいないことがわかったこと。JSR 377 は GUI アプリケーションの標準フレームワークを策定しようとしているのですが、やっぱり難しいのかなぁ....
TUT6825 Project Jigsaw Hack Session
壇上にいるのは Mark Reinhold、Alan Bateman、Manday Chung。
前に書いたように、チュートリアルのくせに Q&A セッションだったこのセッションですが、Alan と Manday がちょっとだけデモをしてくれました。
デモをしたのは、2 つのコマンド、jdeps と jlink です。jdeps が依存性を調べるコマンドで、jlink が JRE のイメージを作るコマンドのようです。
jdeps は JDK 8 にも含まれているのですが、Project Jigsaw 用に拡張されているようです。どのモジュールを必要とするかの一覧を表示することができます。
さらに、依存関係から、依存関係を記述する module-info.java を作成してくれるようです。
そして、jlink は JRE を作ってしまうコマンド。必要なモジュールだけを集めて、JRE を作れるようです。これ、なにげにすごいことかもしれない!
javapackager コマンドと組み合わせれば、アプリケーションの配布も小さくてすむし、かなり便利かも。
CON6712 Enhanced Process APIs
スピーカーは Roger Riggs。Roger といえば、Date and Time API の Oracle 側の責任者でしたけど、Java SE 9 では Process APIs の担当になったようです。
Process APIs は J2SE 5 で導入されたんですけど、イマイチ使いにくい API でした。もちろん、Runtime#exec メソッドを使うことを考えれば、少しは楽になっていますが...
Runtime#exec メソッドで分かると思いますが、Process API は外部プロセスを制御するための API です。今は Runtime#exec メソッドも内部で Process API を使うようになっています。
それが 10 年以上の歳月の後、変更されることになったわけですが、何が変わったのでしょう。ところが、このセッション、とても不親切で、どこまでが既存のメソッドで、どれが新しい部分なのかさっぱり分からないんですよね。なんだかなぁ....
Process クラスでは onExit メソッドなどが追加されたようです。onExit メソッドの戻り値の型は ComputableFuture クラス。ということは、外部プロセスが終わったら、次に何かするのを簡単に書けるというわけです。onExit メソッドに関してはセッションの後半でいろいろ解説してましたけど、ComputableFuture の使い方的になっていました。
また、ProcessHandle インタフェースが追加されました。MethodHandle のプロセス版だと思えばいいのかな。
そして、プロセスの情報は ProcessHandle インタフェースのサブインタフェースである ProcessHandle.Info インタフェースで取得できます。実行ユーザや、コマンド名、引数、実行時間などが取得できるようです。これらはすべて型が Optional クラス。OS によって取得できるものと取得できないものがあるようです。
最後に紹介していたのが、プロセス間のパイプ。今までプロセスの出力を、他のプロセスの入力に直接パイプで流し込むことができなかったのですが、それもできるようになるようです。でも、イマイチよく分からん。
そういえば、このセッションに I18N チームの佐藤さんが聞きに来ていました。I18N チームも Rogger が所属する Core Library グループに含まれることにことになったようです。
CON5107 Prepare for JDK 9
再び、Project Jigsaw 関連のセッション。スピーカーは Alan Bateman ですけど、Mark と Manday も壇上に上がってます。途中から Alex も。
このセッションでは Java SE 9、主に Project Jigsaw に合わせて、アプリケーションやライブラリの作者が用意すべきことを説明したセッションです。
Java SE 9 でコンパティビリティが保たれない点として以下の項目があげられています。
- Encapsulate most JDK-internal APIs
- Remove a small number of supported, JCP-standard APIs
- Change the binary structure of the JRE and JDK
- Remove the endorsed-standards override and extension mechanisms
- New version-string format
- Underscore not allowed as a one-character identifier in source code
下の 2 つ以外は Jigsaw に由来するものです。一番最後の _ を単独で変数として使えないのは、Project Lambda に関わることで、Java SE 8 では警告が出ていたはずです。
まず、内部 API を使えないようにするというのは、Jigsaw の目的の 1 つです。sun.* などのパッケージは内部的に使うもので本来は使うべきではないのですが、今までは使えてしまいました。
特に多く使われているのが、sun.misc.BASE64Encoder と sun.misc.Unsafe です。BASE64Encoder は別の API が用意されたので、そちらを使うべきです。
問題は Unsafe。そこで、JEP 260 では Unsafe のようなクリティカルな内部 API は Java SE 9 で deprecated にして、Java SE 10 で廃止という流れになるようです。
クリティカルな API としてあげられていたのが、以下の項目。
- sun.misc.Unsafe
- sun.misc.{Signal,SignalHandler}
- sun.misc.Cleaner
- sun.reflect.Reflection::getCallerClass
- sun.reflect.ReflectionFactory
内部 API を使っているかどうかは jdeps コマンドで調べられます。jdeps の起動オプションで -jdkinternals をつけると、使用されている内部 API の一覧を出力してくれます。
また、クリティカルではなくて、カプセル化されてしまった API も -XaddExports を使用すれば、使えるようです。ただし、あくまでも移行措置だと思っていた方がいいと思います。
次の削除される API ですが、java.util.logging.LogManager と java.util.jar.Pack200 の PropertyChangeListener に関するものです。これらも Jigsaw 関連なんだそうですけど、よく分からず ><
JRE と JDK の構造の変更はライブラリがモジュール化されたからです。かなり変わるようなので、JDK_HOME 以下のディレクトリ構造を決め打ちにしているようなアプリは注意が必要ですね。
そのほかに java のオプションの -Xbootclasspath や -Xbootclasspath/p などが使えないようになるようです。
バージョン番号は JEP 223 に書いてありますけど、基本的には 1.9 はやめて 9 にするよ、ということのようです。また、Update Release はマイナーバージョンアップになるようです。ここにきて、マイナーバージョンアップが復活するとは思いませんでしたよw
CON1868 Shenandoah: An Ultralow-Pause-Time Garbage Collector for OpenJDK
スピーカーは Red Hat の Christine Flood。
Shenandoah は Red Hat が主導している新しい GC の手法なんですが、イマイチ分からん。OpenJDK のプロジェクトなので、サイト見に行ってもあまり情報がない....
ちなみに、Shenandoah はバージニア州の川もしくは地域の名前のようですね。
Shenandoah の目標は 100 GB 以上のヒープを、10ms 以下のポーズタイムで GC すること。かなり意欲的な目標です。
GC 全体の手法がよく分からないのですが、どうやら G1GC を改良した GC のようです。CMS や G1GC では他のアプリケーションスレッドが動作している状態でも、GC のスレッドを動かしています。Shenandoah はこの Concurrent のスレッドを増やしているのが特徴なのかな。
Parallel GC のように使える限りのスレッドをすべて GC に割り当てるのではなく (当然、Parallel GC が走っている時はアプリケーションスレッドはポーズします)、Shenandoah では余っているスレッドを割り当てているようです。
SpecJBB での G1GC との比較だと、かなりポーズ回数や時間が減っていることが分かります。
でも、もうちょっと詳しい解説がほしいなぁ....
BOF7768 Visualize Log Files for Troubleshooting Java Applications
cero_t と石田さんのセッション。
なんかグダグダでイマイチ。直前まで内容が決まっていなかったようで、石田さんはオープニング以外はほとんど喋らないし。
日本語だったらどうにかなったかもしれないけど、英語でそれはまずいよね。
しかも、cero_t はポスチャーが悪いので、話に信憑性や信頼性がなくなってしまうのです。話題がどんなに興味深いものであったとしても、ポスチャーの悪いと聞いてもらえなくなるのに.... 限に、途中退席者が多かったのは、そういうところにあると思うんですよね。
特に欧米でプレゼンをやる時は、ポスチャーがとても重要!!
おまけ #1
上に書いたように、ランチにいって、Unsafe のセッションに入れなかったわけです。一緒にランチに誘った @bitter_fox くんにはとても悪いことをしてしまいました。
ぽっかり時間が空いてしまったので、20 周年の T シャツをもらいに行ってきました。
Java SE のセッションは Hilton なのですが、T シャツは Park 55 なので、なかなか行きづらかったんですよね。単に T シャツをもらえるだけかと思ったら、その場でプリントしてました。いわゆるシルクスクリーンというやつです。しかも 2 色摺り。
これはなかなかいいですね。
それにしても北斎がこんなところにも使われるなんて、ほんとすごいことです。
おまけ #2
まだ時間があったので、@bitter_fox くんとは別れて、パビリオンへ。
パビリオンがまた縮小されているような気がするのですが... なんとも寂しいものです。
去年のパビリオンではアルデバランの Nao がいっぱいいたのですが、今年は Pepper のようです。
そこでたまたま会ったのが David。あれっ、昨日のセッションではひげはやしていたのに、今日はひげがない。
聞いてみたら、昨日私が Facebook にあげた写真を見て、ひげが汚らしいように感じたので、今日剃ってしまったと。そうだったんだ! でも、ひげない方がいいと思うよ。
David が Pepper に "Shake hands" とか "Hug me" などと話しかけても、一切無視されていたのが ^ ^;; ノイジーな場所だからしょうがないとは思うけど、反応する人にはちゃんと反応するので、何かが違うんでしょうねw
おまけ #3
今日は Taylor Street を封鎖して作られている Duke Cafe で Nll Pointers がプレイするというので、大山さんと聞きにいきました。
今年の Null Pointers はちょっと違う。なんと GS の伊藤さんがドラムとして参加されているのです。伊藤さんに聞いたところによると、バンドで練習したのは土曜日がはじめてということなので、なかなか厳しいですね。
ちなみに Null Pointers はコミュニティのバンドで以前からメンバをその都度代えながら、綿々と続けられているバンドです。
オリジナルはもちろんなくて、いわゆる懐メロ系のカバー。懐メロといっても、演歌ではないですけど。
なかなか楽しめました。
0 件のコメント:
コメントを投稿