本日は、http://www.oracle.co.jp/events/javaday/2016/ に参加してきました。
なお、午前中は会社で仕事をして、午後からの参加でした。
会場は、東京マリオットホテル、品川駅から10分ほどの御殿山です。お昼を食べる余裕がなく、途中駅でパンを買ってきました。
ホテルに付いた後、会場の場所が分からずさまよってしまいました。入り口に案内がなく、あちこちうろうろしてやっと地下に降りて受付の案内板があり会場にたどり着くことができました。
さて、午後の部最初のセッション Java SE 9 Overviewの会場に入りました。
入り口を入るときに会場係のお兄さんが「立ち見です」と言ってたので、壁に沿って中間まで進んでみると、前の方の席がちらほら空いているように見えました。行ってみるとそこそこ空席がありました。
Java SE 9 Overview
米オラクルのBernard Traversatさん。
- Java 9の第1優先事項はセキュリティ
- JVMプロセス間でもっとメモリ共有してメモリ使用量を削減
- モジュールシステムの導入（Project Jigsawのことですね）
- G1GC
- JShell
- JDKのバージョン表記文字列の変更（ルールの明確化）
- sun.misc.* と sun.reflect.* は削除。但し次は残る
- Unsafe, Signal, SignalHandler, Cleaner, Reflection::getCallerClass, ReflectionFactory
- JDK 9の機能は、JEPを見よ
- Java SE Advanced Management Console
- 複数のPCにJavaのバージョンがどう入っているかなどを管理（インベントリ管理みたいなもの？）
Java 9の先の話
- Object Data Layout
- Project Panama
Java SE 9リリース予定まで1年を切って、そろそろOpenJDK 9の開発もフィーチャーコンプリートとなるので、そろそろ固まってきたという印象です。
Project Jigsawではじめるモジュール開発
Java Champion 櫻庭 祐一さん。
- 今のJARには2つの問題
- ごちゃごちゃっとしたクラスパス
- 巨大な標準APIのJAR（rt.jar）
- JARは依存関係、バージョンの仕組みがないため「JAR HELL」を招く
- Hadoopを実行するときは130個（！）のJARをクラスパスに定義
- Project Jigsawでは、モジュールという仕組みを導入し、依存関係、公開、バージョンの3つを制御（ただしバージョンの制御は弱い）
- 従来のJARの仕組みは継続して利用可能（unnamed なmoduleとして扱われる模様）
- モジュール定義はmodule-info.java（ファイル名固定）に記述し、これはソースコードのディレクトリのトップに配置する
src - net - jitb - jigsaw -+- Peace.java | +- PeaceFactory.java | +- internal - Cutter.java +-- module-info.java
module net.jitb.jigsaw {
}
- requires 文（末尾のsは複数形のsではなく、三単現のsなので、複数のモジュールをrequiresするときはひとつずつrequires文を記述）
- クラスライブラリ net.jitb.jigsawパッケージ を作成し、この中のクラスがJavaFXを利用する場合、次のようにモジュール定義を記述
module net.jitb.jigsaw {
requires javafx.controls;
requires javafx.graphics;
exports net.jitb.jigsaw;
}
-
- exports に記載するのはパッケージ名、requiresに記載するのはモジュール名、まぎらわしいので注意を
- net.jitb.jigsawモジュールを使用する上位のモジュールで、net.jitb.jigsawモジュールが依存するモジュールを直接使う場合、上位のモジュールでrequires文を記述するか、requires public文に替えて依存するモジュールを上位に公開する(requires public javafx.graphics;）
- アプリケーションを実行する際、mainメソッドを持つクラスをモジュール外部（javaランチャ）から呼び出すので、メインクラスを含むパッケージはexportsしておく必要あり
- javacコマンドに、モジュールが配置されているパスを指定する-mpオプションが追加される
- mpオプションで指定するのはディレクトリ
- jdepsコマンドでモジュールの依存関係を確認できる
- jlinkコマンドで、JREから必要なモジュールを抽出してカスタムなJREを作成可能
その他
Java Concurrency, A(nother) Peek Under the Hood
日本オラクルのデイビッド・バック さん
- シングルスレッドは学校の宿題まで
- ハイゼンバグが厄介
- メモリモデルの話
- ここで特殊相対性理論の話に
- プログラムのコードが、書かれた順番に実行されるとは限らない、ということを、相対性理論での観測者が異なると観測される事象の順番が同じとは限らない、ということと対比
- Javaのメモリモデルは当初はsynchronizedとvolatileについて定めていたが、JSR-133でvolatileのhappened before、finalについて追加された。
- JEP 188でメモリモデル改善
- デモ）2つのスレッド間で happened beforeなイベントがないときに最適化の違い（HotSpot クライアントコンパイラとサーバーコンパイラ）で動きが変わる
- JITコンパイラの生成したコードをHSDISでIntel CPUコード（アセンブリ言語コード）で確認
- 書籍「Java並行処理プログラミング」超おすすめ
Java 9で進化する診断ツール
NTTコムウェア株式会社末永 恭正さん
- jcmdとjhsdbのコマンドだけ覚えて帰ってね
- jstack, jmapなどはもう使わない（JavaDocに「試験的」と書かれているツール）
- jcmdは JDK8にも入っているが、JDK9で拡張
- hsdb
オラクルコンサルが語るJava SE 8新機能の勘所
日本オラクルの伊藤 智博さん
Java SE 8 で導入された次の3つの機能が従来の記述に対して優位性があるかをパフォーマンス観点で解析しました、という内容のセッションです。
Java Flight RecorderとMission Controlを使って性能の計測と解析を実施、CPUリソース、JavaVMに中断された時間（GC）、処理時間を順次確認。
今回のデモでは、いずれも既存の書き方に対して同等以上でした。以下トピックメモ
- Stream APIのparallel()の有効性を確認するのに物理36コア（72スレッド）のマシンを使用！ 途中でGCが発生しないようメモリも128GB(? 256GBだったかも）を割当
- まずCPU使用率を見て、測定プログラムがCPUを使いきっているかを確認
- GCの実行回数を確認（比較対象の双方でほぼ同じGC状況かを見ていたようです）
- 処理時間は、1億回実行して測定
- Stream APIのparallel()では、並列数を1から72まで増やしながら計測
- 物理コア数（36）までは、コア数を増やすと処理時間がリニアに減少
- 物理コア数を超えて並列処理すると、処理時間はほぼ横ばい（72スレッドでは36スレッドでの処理時間より10%程度速い）
