【Java】Java Day Tokyo 2016 各Sessionまとめ #JavaDayTokyo (2016/5/30追記)
2016/5/30追記
Oracle社より、資料の公開がありましたので、URLを追加しました。
＜資料＞
===================================================
昨日参加したJava Day Tokyo 2016 のセッションごとでのまとめです。
基調講演(Keynote)はこちら
基調講演の記事でも記載させていただきましたが、Java Day Tokyo 2016を開催いただいた日本オラクル社様、US Oracle社様、協賛会社の皆様、参加者の皆様、その他運営のご協力された方々、とても有意義な日をありがとうございます。
それでは私の受けたセッションごとでのまとめをさせていただきます。
間違い等ありましたらご指摘のほどお願いいたします。
★Session1★Introduction to MVC 1.0 (JSR 371)
→将来に向けてのMVCに関するお話
★Session2★使ってみよう！ Oracle Developer Cloud Serviceによるクラウド型開発でJavaEE7
★Session3★Java Concurrency, A(nother) Peek Under the Hood
→JVMの開発者が考えるメモリ管理、スレッド管理の重要性に関する解説
★Session4★Java 9で進化する診断ツール ( 4:15 PM-5:05 PM )
→OpenJDK開発者が語るJava9時代のJava診断ツール
★Session5★実システムのためのJava EE 7 ( 5:20 PM-6:10 PM )
→Javaが好きで、もっと言うと標準化された標準が大好きなエンジニアが考える実業務でのJavaEE世界について
[Session1]Introduction to MVC 1.0 (JSR 371) ( 1:00 PM-1:50 PM )
講演者：Oracle Devid Delabassee氏
言語：英語(同時通訳付き)
詳細：Introduction to MVC 1.0 (JSR 371)
資料：http://www.oracle.co.jp/jdt2016/pdf/1-B.pdf
主要な内容：将来に向けてのMVCに関するお話
もっと分かりやすく書くと、JavaEE標準APIを用いたMVCモデルの展望に関する解説です。
まず、MVCは幅広く使われている１０年以上使われており成熟しているインターフェースである。
ここで改めてMVCモデルについて振り返り
モデル：
ユーザインターフェースに必要なデータの保持を行う。
ビュー：
ユーザがスクリーン上に見るもの。
インタラクションを起こすボタンなど
(Webの場合はJSP)
コントローラ：
MVCモデルのコンピュータエンジンになる。
ビジネスロジックはコントローラーが実行する。
そして、あまり意識したことないかもしれないが、MCVモデルには2通りのパターンが存在する。比較を含めてるとこういった形になる。ただしどちらが良い悪いというわけではない。
コントローラがほぼ主要な処理を行う。
開発者はモデル、ビューを開発することになる。
どちらかと言えば、高級なMVC
アクションベースMVC：
開発者は、コントローラ、モデル、ビューすべての開発作業が必要になる。
どちらかと言えば、低級なMVC
そして、JavaEE8で追加された「JSR371(MVC1.0 JSR)」のお話。
MVC1.0 JSRとは、アクションベースのMVCモデルのフレームワークである。
なぜ開発作業が煩雑なアクションベースを選んだのか？
それは開発者がスクラッチ(一から開発)できる機会を残したい。そして、Javaの設計思想を最初からやり直すことは避けたかったという経緯がある。
現在提供しているJava APIで提供できるものは提供しよう！
→モデル：CDI、Validation、JPA
→ビュー：Facelets、JSP、そのほかにも
→コントローラー： JAX-RS
(そして、JAX-RSやCDI、Faceletsのサンプルソースを紹介)
最後にまとめ
→既存の言語、APIを利用できることは重要なことである
アクションベースMVCを活用することも悪いアイデアではない。
→開発者が自由にカスタマイズできることは良いことである。
古いリソースを管理している開発者は徐々にでも良いので新しいMVCに移行することも検討をしていくことを進める。
[Session2]使ってみよう！ Oracle Developer Cloud Serviceによるクラウド型開発でJavaEE7 ( 2:05 PM-2:55 PM )
講演者：日本オラクル 関屋氏
言語：日本語
詳細：使ってみよう！ Oracle Developer Cloud Serviceによるクラウド型開発でJavaEE 7
資料：http://www.oracle.co.jp/jdt2016/pdf/2-D.pdf
主要な内容：オラクルクラウドの統合開発環境についての紹介とデモ
Oracle Developer Cloud Serviceでは、開発サイクルに必要な様々なツールをクラウドで提供している。
例えば、開発機、ソースコード管理、ビルド、デプロイなど。
オンプレ(クローズド開発)もサポートしている。
(ライセンスに関する紹介、デモ)
Oracle Developer Cloud Serviceを利用してJavaEE7の開発を行うにはどうしたらよいか？
開発環境
Gitが使える統合開発環境でOK!
ビルド
Maven(Hudson)を利用を推奨。
依存ライブラリをダウンロードできる仕組みがあるため。
たとえば、ojdbcドライバーのjarを明示的にアップロードする。
テスト
レポートを出力できるのはJUnitのみ。
アプリケーションの公開
オンプレミスのJavaEEサーバ利用可能
Java Cloud Serviceほか、クラウドも利用可能
＜QA＞
[質問]
日本オラクル社さんでの実務での実績及び実用度はどのようなものでしょうか？
並大抵のIT企業では測りきれないレベルの膨大なソースコードやビルドを行っていると思いますが。
[回答]
社内での全面適用はしていませんが、やはり向き不向きがあるので、このサービスが向いている業務については積極的に採用している
[質問]
フリーライセンスについて利用期限はあるのか？
[回答]
1か月である。
[Session3]Java Concurrency, A(nother) Peek Under the Hood ( 3:10 PM-4:00 PM )
講演者：日本オラクル David Buck氏
言語：日本語 ぇ？日本語？ぺらぺらでした。。。
詳細：Java Concurrency, A(nother) Peek Under the Hood
資料：（まだ未公開）
主要な内容：JVMの開発者が考えるメモリ管理、スレッド管理の重要性に関する解説
付けくわえて、最適化(コンパイラ、JIT、ハードウェア)によって起こるデータ不整合をいかに防ぐか？
まずは、マルチスレッドに関しての意識合わせを行った。
私は並行処理を書かないから、スレッド関連のバグには出会わない？
Webサーバはマルチスレッド
GPUアプリもマルチスレッド
ライブラリも呼び出し先でマルチスレッド利用される場合も
バッチ処理の場合も、マルチスレッドのほうが効率的
つまり、Javaの開発者がマルチスレッドを意識しなくていい機会なんてない。
そして、こんなところでも、落とし穴が。。
JITの最適化
ハードウェアの最適化
コンパイラによる最適化
下記の絵は、JIT、ハードウェア、コンパイラどれでも起きうる最適化の例
そして出てくる考え方が「メモリモデル」
書き込まれた値が正しく読み込まれるか確認する仕様（書き方）
→ここで言いたいのは、マルチスレッドであろうと、最適化であろうと「正しいデータが読み書きできて当たり前だ」ということ
そのうえで原則を振り返る
シングルスレッドコードの振る舞いが変わってはいけない。
余談）イベントがA,B,Cとあった場合、見る人によって「A,B,C」とみる人もあれば「C,B,A」とみる人もいる。これは
マルチスレッドについて
スレッドによって、観察(実行)する順番がことなる。
メモリモデルの定義
開発者が頼ってもいいふるまいを明確にする。
プラットフォームがやってもいい最適化を制限する。
よって、これを実現するには、以下のJavaの機能を使う。
抽象的なほど強い同期化、具体的なほど弱い同期化
そして未来のJava
現在でもJavaの開発中
JEP-188/JMM9
JVMレベルでの仕様
C11/C++11のモデルとの互換性
JDK6以降の新機能を含む
まとめ
できるだけ高いレベルの抽象化を利用して、メモリモデルを実装する。
これにより、スレッドや同期化による潜在バグをなくすことができる！
最後に注意事項
メモリ関連の問題は、まれにしか発生しない問題が多い
JREやプラットフォームによって挙動画変わる
避けるべき行為
synchronized(new Object()){}
動くようになるため、やみくもにvolatileを追加する。
→上記コードはJVMによって挙動が変わる。
JVM屋さんいからみたテスト方針
テストは不可欠
できるだけ本番環境と近い環境でやること！
同じJRE
同じハードウェア
同じ設定
そして、デイビットさんがJavaをかくなら絶対に読んでほしい本はこれ！
先述で述べた通り、Javaで並行処理を意識しなくていい時なんてない。
だからこそ読んでほしい1冊だそうです。
＜ＱＡ＞
[質問]
現在、自社フレームワークの開発に関わっています。
この際にやはりスレッドセーフティの問題が付きまといます。
(特に日付処理、特にSimpleDateFormat )
ただ、スレッドセーフティを意識し過ぎるとレスポンスに影響し、現場から苦情がきます。
デイビットさんの持論として、こういった場合どうするべきでしょうか？
[回答]
フレームワークの開発ということを考慮すると、スレッドセーフティについてはドキュメント化(JavaDocや通常ドキュメント)するべきである。
フレームワークとして、「どういう使われ方をするか？どういう使い方にさせるか？」を意識するのがポイントになってきます。
ですので、１００％のスレッドセーフティは求める必要はない。0か100じゃなく、「一定までは許容するよ。こういう使い方したらスレッドセーフティじゃなくなるよ」ってドキュメントに明言してあげるのがよいかと思う。
＜最後に謝辞＞
デイビットさん！業務での相談と、記念写真ありがとうございました！
すっかりデイビットさんのファンです(笑)
ぜひ、また講座や議論などさせていただけると嬉しいです！
[Session4]Java 9で進化する診断ツール ( 4:15 PM-5:05 PM )
講演者：NTTコムウェア 末永氏
言語：日本語
資料：http://www.oracle.co.jp/jdt2016/pdf/4-A.pdf
主要な内容：OpenJDK開発者が語るJava9時代のJava診断ツール
Java9時代において使う診断ツールは
jcmd 情報収集・設定変更
jhsdb プロセスハング
だけ！
j系コマンドの実験的と書いているものは廃止
今回のセッションは、文章での説明が難しいのでスクリーンベースでお話しします。
Java9から登場したコマンド
例：GCログを出力してみる
ログのローテーションに関してお客様から「これは０時、これはサイズで」といった出力は気持ち悪いという指摘から作ることに
トラブル時のログを収集したい
VM.info
クラッシュさせずにクラッシュ時と同等のログを出力できる
オプションつけ忘れた。。。
CM.set_flag
非推奨パラメーター(XX)は設定できない
Compiler.directives_add
JSONの例を紹介
パラメーターにJSONを食わせる
過去事例：JDK7でJITコンパイラのバグでハングする事象があった。
→こういう場合に、JITコントロールすることによって、原因調査の高速化
自分の作ったアプリはJITの恩恵をどのレベルで受けているのか？
Compiler.codelist
ヒープの状況をざっくり知りたい
GC.heap_info
jcmdの弱点
ターゲットプロセスがハングしたら使えない？！？
そんなときの強い味方
jhsdb
Java9から新しく入った診断ツール
コア解析、プロセス解析の強い味方
システムコールして診断するため、ハングとか関係なし
新ツール
jnsp
実は昔からありました。
hsperfdataの中に入っているパフォーマンスカウンタを読み込む
問題があったため、修正して正式デビューしたツール
コアからカウンタを読み込むのが大変
例：FullGCの累積実行時間を出してみる。
いろいろ、データを手繰っていく。。。。
OpenSDKのソースを読む必要あり
jsnapがあれば。。。
コマンド１発。あとはgrepするだけ！
(その他いくつかのツールの紹介がありましたが割愛)
まとめ
Java9時代の解析ツールは？
jcmd
&
jhsdb
だけ覚えておけば十分！
[Session5]実システムのためのJava EE 7 ( 5:20 PM-6:10 PM )
講演者：楽天 岩崎氏
言語：日本語(スライドは英語)
資料：http://www.oracle.co.jp/jdt2016/pdf/5-A.pdf
主要な内容：Javaが好きで、もっと言うと標準化された標準が大好きなエンジニアが考える実業務でのJavaEE世界について
まず、JavaEE7の出来が良い。だからこそ、JavaEE8は期待している。
足りないのはロギングぐらい？log4jが入ってればもう他はいらないよね？ぐらいに思っている。
で、JavaEEのバージョンアップのお話に移ります。
JavaEEはバージョン毎に少しずつバージョンアップしていくこと(スモールアップデート)が重要。
そして、やっぱり標準APIを使うことが大切
なぜか？
OSSを利用しているとする。
Springを2から3に上げると思うとゾッとしませんか？
↓
でも、JavaEEのソースコードの寿命は長く、案外古いソースを
業務アプリの寿命は長い。だからこそ標準APIが重要になってくる！
JavaEEの歴史
でも、標準APIでもバージョンアップ量が増えれば増えるほどコストがかかる。
だからこそ、スモールアップデートが大切です。
イメージとしてはアプリケーションサーバが成熟(半年～１年)してから適用するイメージ。
※すぐに上げると、JavaEE本体やAPサーバにバグが残っている場合がある。
また、既に廃止されていて、後継バージョンの存在しないアプリケーションサーバの場合、乗り換えはどうするんだ？
だからこそ、JavaEE標準準拠でいきましょう！
後継バージョンが廃止なんて自体に陥らないために、 常に新しいアプリケーションサーバの情報を注視してみておく必要がある。
ここで、JavaEE標準に基づいて作られているシステムの移行を簡単にまとめます。
移行に関するチュートリアル簡単まとめ
■JavaEE6からJavaEE7への移行
定義
web.xmlとapplication.xmlのURLを書き換えるだけ
フロントエンド
JSF 2.1から2.2へ
バックエンド
EJB 3からCDI1 1.1、JPA2.0からJPA2.1
■JavaEE5からJavaEE7への移行
JDK6からJDK8
フロントエンド
JSF 1.2から2.2へ
バックエンド
EJB 3からCDI1 1.1、 JPA1.0からJPA2.1
■JavaEE4からJavaEE7への移行
JDK1.4からJDK8、 アノテーションを追加
フロントエンド
Struts1.xから2.2へ
バックエンド
EJB 2.0 or Spring 1.0 からCDI1 1.1、 Hidernate2.x、3.x からJPA2.1
■JavaEE3からJavaEE7への移行
JDK1.3、1.4からJDK8
・・・(想像できない。。。)
■JavaEE2からJavaEE7への移行
JDK1.1、1.2、1.3からJDK8
・・・(想像できない。。。)
■pre-EEからJavaEE7への移行
JDK1.1からJDK8
・・・(想像できない。。。)
改めて
EOLを迎えたJavaシステムをいつまで使い続けるのか？
今後のバージョンアップを考えて、標準にのることが大切。
[総括]
Java Day(Java One含めて)初参加いたしました。
改めて、Java言語の奥深さを印象付けられた1日でした。
今回のJavaのセミナーの中で、特に感化された、興味を持った項目は４つあります。
１．Java8の現状と、Java9、そしてそれ以降のJavaの展望
普段Javaの開発や、運用を行っている人が感じている「VMの起動の遅さ」「VMのメモリ使用量の多さ」について、Oracle社のセミナーで明言し、改善することを確約したのはとても大きく感じた。
仮想マシン(VM)を使うことでマルチプラットフォームを実現しているJavaにおいての最大の問題点を「こういった形で解決する」といってくれたことは今後のJavaにおいて大きな1歩だと感じた。
２．Session3でのメモリに関する解説
VM開発者の視点からみた、メモリの考え方、スレッドセーフティの考え方について、理解しているつもりであったが、まだまだ、自分の技術レベルが甘いことを実感した。
講義後、デイビットさんにご質問する機会があり、「自社フレームワーク開発でのスレッドセーフティの考え方」について質問した際に自分の中では「0か100」で考えていたものを「まずはドキュメント化、そしてどこまでスレッドセーフティを担保するか？で考えてみてはどうか？」とのお言葉を頂いた。
３．Session1、及びSession5を受けてのJava標準API利用の重要性及び標準準拠の重要性
どうしても、過去からの経緯でOSSを多用することが多いが、標準APIが充実してきている。
Session5でのJavaでの下位互換の担保についても、互換性の高さが見え、過去にStrutsのバージョンアップができず、悔んだ経験もあり、「標準準拠」と「OSSの活用」に関していろいろと考えさせられた
４．同じJavaエンジニアでも「ランゲージ」、「VM」、「セールス」「業務アプリ」の各エンジニアでは考え方や方向性が違う
基調講演と、セッション５つを受講したがそれぞれ同じ「Javaエンジニア」であるが、立場によって、方向性や考え方が違う印象を受けた。
「VMエンジニアだからこそわかること」「ランゲージエンジニアだからわかること」など様々な視点のご意見が聞けたことは大きい。
[余談]
本気で参加するなら、バッテリーの持つモバイルパソコンと、交換バッテリー持っていって正解でした。
あれをメモするには手書きでは追いつきません。。。
また、英語ができると、米国エンジニアと会話ができ、楽しめると思います！
