torutkのブログ

ソフトウェア・エンジニアのブログ

JavaOne報告会@東京に参加 #jjug #j1jp

JavaOne 2016 報告会 @ 東京 - 日本Javaユーザーグループ/Japan Java User Group | Doorkeeper

JJUG主催のJavaOne参加者による報告会が昨日開催されました。参加メモの日記を書きます。

Togetterまとめ(by @yamadamn)
JavaOne 2016 報告会 @ 東京 #jjug #j1jp - Togetter

伊藤 敬さん (日本オラクル)

  • 今年はJavaOne for Kidsが開催期間前の9/17に1日開催
  • 9/16にJava Champion Summitが開催
  • 今年のテーマは「Java Your Next (Cloud)」、わざわざ(Cloud)と付けてる
  • Java SE 9は来年7月に延長
  • 今後、DockerベースのJDKを提供する予定、Keynote直前にスライドが用意されたほど直前に決まった模様
  • Keynoteでの日本人登壇者多し

久保田 祐史さん (@sugarlife)

スライド公開するのでメモ取らなくて結構です。写真はどんどんツイートしてね。
スライド資料「JavaOne 2016 Java SE Feedback」

  • JavaSE 9は、2回延期している
  • Jigsaw は、JAR Hell対策、依存性を付け、公開先を制限し、バージョンを付けられる
    • JDK内部のモジュール化に難航し、JavaSE 9再延期の原因に
    • まだまだ変更が多いので昨年の情報は古くなってる
    • コマンドの日本語ヘルプは古いので英語ヘルプを見よう(コマンドオプションで言語をenに指定→スライドp.14)
  • Reactive Streams(The Flow API
    • 詳しく話すと時間がかかるので参照先を見てね
  • JavaSE 9への移行にあたっての注意点を重点的に話します
    • 内部API(非公開)を使っているもの
    • クラスローダー
    • JVM/GCログが変更、JVMオプション大変更、ログ出力フォーマットも変更、GCViewer等影響あり
    • ついに非推奨(@Deprecated)APIの削除が発生します。Jigsawのモジュール化で支障が出るものなど一部分

と、ここで不覚にも寝落ちしてしまいました(夜更かしが多い生活を反省)

Java SE 9についての感想

JavaOneのCore Java Platformトラックのセッションのサマリを期待していましたが、今回はJava SE 9限定の話でした。

Javaでアプリケーションを書く立場であれば、Java SE 9は言語仕様やライブラリがどかっと入るものがなく若干のアップデートにとどまるので、さほど気にしなくてもよさそうです。

一方、アプリケーションのビルド、リリースおよび実行環境の設定・調整・問題対応をする立場であれば、Jigsaw、JVMオプション・ログの変更などによる大変革が発生します。

動かしてみるまで影響が見えないので、Java SE 9がリリースされてから移行の検証を始めると、いろいろ問題が噴出するという事態が予測されます。

Java SE 9への移行ポイントがまとめられているので、来年Java SE 9がリリースされる前後にもっと時間をかけて聞きたい内容です。

Java Champion 寺田 佳央さん (@yoshioterada)

スライド資料「JavaOne報告会 Java EEの今後について」

  • Java EEの将来について、日本で書かれる情報は表層に過ぎない
  • キーワードはマイクロサービスとリアクティブプログラミング
  • Java EEの将来への不安(開発が停滞)と、Java EE GUARDIANSの活動
  • Microprofileという動き
  • Java EEのリリースと製品リリース
  • Java EE 9
    • マイクロサービス
    • NoSQL

ボリュームすごすぎな内容です。

感想

こちらもJavaOneの報告というよりは、寺田さんJava EE愛を語るセッションの色合いが濃いものでした(悪い意味ではなく、いい意味です)。

今のJava EEがいいか悪いかという評価については、観点が必要になるので、Java EEを使う応用分野として次の2つを想定します。

  1. 基幹系、社会インフラストラクチャ、工場の生産システムなど、開発してから10年はふつうに動かし続けるようなシステム
  2. ECサイト、情報提供などのWebアプリケーションで、開発してから2,3年でスクラッチ&ビルドするようなシステム

前者(1.)は、開発時に使用したJava EEバージョン上で動作するソフトウェアが以後ずっと、計算機・OS・ミドルウェアをリプレースしつつ*1動作し続けることが求められます。
Java EEには新機能取り込みよりも、安定性(非互換な変化がない)を求める立場です。

後者(2.)は、頻繁に開発・リリースを繰り返す分野で、何年も前に作ったアプリケーションソフトウェアを変更せずに動かす必要性はないので、互換性は重視せず、今すぐに競争力のあるものを効率的に(早く、安く、うまく)作れる基盤たることをJava EEに求めます。

Java EEの仕様は、基幹系からWebアプリケーションまで含んだ仕様大系なので、この2つの立場のどちらにも採用され、その結果、それぞれの立場から見た不満が出てくるのかと思います。それにしても会場で、いまのJava EEに満足している人がほぼ皆無だったのは、前者の立場の人はいなかったかのかなぁ。。。

今回紹介のあったMicroprofileは、この後者で望まれる技術がJSR化&Java EE採用を待って不満たらたらになるのではなく、先に実装を進めてしまい、うまくいったらJSR化する、という動きをしてしまおう、というもと理解しました。

マイクロサービスのところでは、マイクロサービスの分散において、想定しているのはJava EEプラットフォームだけなのか、他のプラットフォームのサービスとの連携も想定しているのかが見えませんでした。

鈴木雄介さん (@yusuke_arclamp)さん

スライド資料「JavaOne 2016総括」

  • 標準Javaは進展なし
  • IBMのキャッチコピー「MAKE JAVA GRATE AGAIN」がいい!
  • IBMのJavaVM実装 J9をOpenJ9としてオープンソース
  • J9が使っているEclipse OMR技術は、任意の言語の実行環境を開発するツールキットで、JITコンパイラGC、スレッドライブラリなどが提供され、CRubyに試行?した
  • アジャイル、マイクロサービス、DevOpsなどはもう導入の次のフェーズに移っており、使い方を磨くフェーズ
    • 性能テストでJUnit1日がかりとなりリリースサイクルが遅いのをどうするか?
    • メトリクスをどうとるか?
  • マイクロサービス間の通信をどうするか
    • RESTful over HTTP/1 性能限界
    • サービスチェーン問題(リターンがあるとさらに問題)
    • 通信を抽象化した非同期/非対称なイベント駆動
  • オープンソース、コミュニティ、エコシステム
    • 金が回らないとだめ
  • JavaOneは、Sun/Oracleの話を聞きに行く、から、みんなの話を聞きに行く場に変わってきている
感想

過去2013年/2014年と2回JavaOneに参加して、Oracleのコアなセッション以外に、Java技術をつかってこんなことをしているよ、と応用分野の内容を聞くことができてよかったとの思いがありました。
日本ではなぜか話題にされない(記事にならない)情報なので、まさにJavaOneでしか聞けない(そして日本語情報としては流れてこない)ですね。

末永 恭正さん (@YaSuenag)

スライド資料「Road To Duke's Choise Award」

HeapStats開発秘話、でした。聞けてよかった内容です。
アセンブラまで使っている、HotSpotVMのC++のバーチャルテーブル屠っている、などかなりの作り込みがあります。

久保田 祐史さん (@sugarlife) 第2部 Jedi役で参加するまで

JavaOne Community Keynoteスターウォーズのパロディ劇にJedi役で参加した裏話を
おもしろおかしく紹介しました。

懇親会

参加者のLT、そして写真で振り返るJavaOneがありました。
実はJavaOneの様子が一番わかるのがこちらでした。

LTスライド(公開分を見つけたら記載)

Jdk9で変更になる(かも知れない)jvmオプションの標準設定
Technical documentation, API, and code examples | Microsoft Docs

全体の感想

今回のJavaOne報告会では、肝心のJavaOneのセッションの内容伝達が少なく(というかあったのか?というレベル)、むしろ懇親会でのLTの方がJavaOne報告会らしい内容でした。

最先端情報を求める人ばかりではないので、Java SE 8の情報やJava EE 7の情報、また、Java SE Embedded(ARM環境)、ツール関連情報もあるとなぁ、などといろいろ思ったりしました。

おまけ

JavaOne 2016参加者のブログ、報告会参加ブログなどをリンクしています。
http://www.torutk.com/projects/swe/wiki/JavaOne_2016_SF

*1:運用期間が長いと、最初に劣化するのは計算機、次にOSと、低レイヤーからとなります。計算機メーカーの保守(故障対応)が5年間というものが多く、5年を経過すると壊れても修理ができないことがあり、通常リプレースとなります。中には長期保守(部品を10年間維持)というのもありますが、それなりにそれなりです。計算機のリプレースとなると、その時点でOSやJava EEサーバー他ミドルウェアも異なってきます。当初開発した古いJava EEバージョン上のソフトウェアが変更せずにリプレース後の新しい環境で、できればバイナリ互換で動くとGood Jobです。