エンターテイメント！！

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

トップ > FW > Java SE 9/EE 8リリースイベント兼JavaOne2017報告会@東京 参加報告

Java SE 9/EE 8リリースイベント兼JavaOne2017報告会@東京 参加報告

FW Java マイクロサービス ログ プログラミング バズワード チーム 性能 論争 開発環境

Java SE 9/EE 8リリースイベント 兼 JavaOne 2017 報告会 @ 東京

公式サイト

https://jjug.doorkeeper.jp/events/66256

開催概要

日時

2017-10-21（土）13:00 - 19:30

場所

ヤフー株式会社 紀尾井町オフィス 17Fセミナールーム
東京都千代田区紀尾井町１ 東京ガーデンテラス紀尾井町

タイムテーブル

時間 内容
13:00-13:30 JavaOne 2017 Overview & Announcements by 伊藤 敬さん (日本オラクル)
13:30-14:20 JDK9, Release Cadence & Future by 久保田 祐史さん (inc. JShell Demo by @bitter_fox) (@sugarlife)
14:20-14:50 Intel's Persistent Memory by 吉田 真也さん(@bitter_fox)
15:05-15:45 Java EE 8 by 西川 彰広さん (日本オラクル)
15:45-16:25 Microservices Topic & Approach by 森下 大介さん(ヤフー株式会社)
16:40-16:50 Fn Project by 伊藤 智博さん(@chiroito)
16:50-17:10 Community&総括 by 横田 紋奈さん(@ihcomega)

動画

www.youtube.com

行こうと思った理由

今は、Java使ってないけど、一番得意な言語であるので、最新情報をキャッチしたかったから。
あと、Javaのリリースがよく分からなかったから、聞きに来たのが大きい。

ちなみに、今は、Typescriptおじさんです。
Javaやってる人なら、簡単に出来るので、第二言語としてはオススメだと思うよ？

感想・まとめ

コードギアスの映画を見に行くか迷ったけど、ギアスは明日でも見に行けるから、こっちを優先。

JavaOne 2017 Overview & Announcement

今年のJavaOneは、機能追加をより早くがテーマだったみたい。

これからの活動方針は、進化の加速と軽量化が主目的なる。
もっと簡単にリリースの提供していくというのが新しく方針に加わった。

Java9への道

もともとはJDK7で考案として、Coin&Lambda&Jigsawがあったが、Java7に載せるのは無理だった。
そのため、以下のような形になった。
java7 - Coin
java8 - Lambda
java9 - Coin完成 Jigsaw

リリースモデル

従来のリリースモデル

機能リリース：２年だが、守れたことはない。。。

その結果、細かな機能追加が遅れてしまい、Javaが時代遅れになりつつある。

新しいリリースモデル

OpenJDKとOracleJDKの差分をなくす
機能リリースを６ヶ月に一回に変更
バージョン表記は、YY.M
更新リリース：３ヶ月（メンテナンス用）
OpenJDKのバイナリで配布。次のバージョンまでの６ヶ月は無償サポート

わかりにくいな。。。。
話を聞く限り、リリースとサポートのサイクルは違っているようだ。
長期サポートは、３年サイクルで決まる。
３年経ったら、その間にリリースされたものは、その後に３年サポート保証する。
そのサポートサイクルが、既存のリリースと同じ感じだな。
新しいリリースは、半年ペースで行われるので、６回のリリースを経た後、３年サポートになる。
20:53の図を見る限り、その認識で問題ないはず。
ただし、無償サポートについては、次のバージョンがリリースされるまで。

ソース管理は、従来だとバージョンごとにブランチがあった。 新モデルだと、リリースラインが１本化。 おそらく、ソース管理がそのほうが楽だからと思われる。 たぶん、svnチックなブランチ管理のせいで、摩耗していることが多かったのだろうな。

どれを使うか、かなりシビアな気がしてきた。 アナウンスにそうなら、３年ごとの最後のバージョンに合わせるのが良さそうな気がする。
サポート単位で、やっぱりJava10とかの命名が必要な気がしてならない。
今のリリースサイクルだと、短すぎて説明が面倒くさいような気がする。

ロードマップの把握がかなり重要になってきそう。 いままでは２年以上のリリースサイクルがあるので、後追いでも十分追いつけたが、これからの新モデルだと、常に情報を追ってないと不味そうだね。 最新機能を追うか／追わないかで、エンジニアの力に差がつきそう。
Java今使ってないけど、主力武器には違いないので、なるべく追う。

JDK9, Release Cadence & Future

WEB+DBの告知。自分は電子書籍の定期購読してるんで大丈夫です。
前は本を買ってたけど、ソースをコピペできるPDF形式の配布は、かなりいいｂ

追加機能は、JEPで確認する。 もしくは、Bugzilla issuetype=JEP

移行は、Migration Guideを読む。 ★あとで翻訳、もしくは読んで見る。

Java9のメリット

  • モジュール化
  • RPEL
  • ライブラリ改善（Coinの残り対応）
  • セキュリティ強化
  • 付属ツールの刷新
  • G1GCやコンパイラの性能改善

そういえば、G1GCはデフォルト化されたので、メモリが小さいところで動作させるのは注意しなきゃな。
すっかり忘れてた。。。

どのライブラリの参照がなくなったのか、コンパイル時に発見することができるようになった。 今まではしらみつぶしに参照していたものがなくなって、楽に解決できるようになったはず。

JShell

REPLツール
LISP, Python, Ruby, Scala, Groovyなどの人気があるのに使われていた。

主な用途は、APIの挙動確認、デモ、プロトタイプ確認。

下記サイトで、Java9入れなくても試せる事ができる。
今後のリリースサイクルは短いので、インストール不要で試せるのはかなり楽。
バージョン指定が今後欲しい機能だな。
もしかしたら、もうあるのかな？

tryjshell.org | Java 9's JShell

コマンドは使い方は以前まとめたので、そちら参照

suzaku-tec.hatenadiary.jp

jshellの特徴

  • 保管機能が強い
  • importの自動補完、変数定義の補完がなされる

コレクションのファクトリ

かなりコード量が減った。
コレクション系は、使う機会が多いので、覚えておいて損はない。
コードと関数を紐付けたり、グルーピングに使ったりする。
以前にブログでまとめた。

suzaku-tec.hatenadiary.jp

イミュータブルでフェールセーフ、最適化された状態 2要素→フィールド実装になったりしている。

StreamAPI iteratorの終了条件や継続条件が使えるようになり、while文に近いことができるようになった。

今後の予定

次はProject Amber
ローカル変数の型推論が加わる。
var url とかできるようになる。
コード記述の煩わしさを解消するのがメインの内容になる。

Intel's Persistent Memory

大容量で割安、不揮発性
Persistent MemoryにオラクルDB乗っけたり、Java動かすようにしてくよ？みたいなアナウンスがあったらしい。

用途

揮発性の大容量メモリとして使う

ヒープをすべてPMに乗っける。

設定簡単。メモリアクセス速度＜大容量メモリのシーンで使える

一部のヒープをDRAMに乗っける

設定が細かく設定できる。速度重視なもので使える。

不揮発性のローカルストレージとして使う

永続化可能なクラス・コレクション・API・トランザクション、ユーザ定義可能なクラス定義が提供されている。

話を聞いて

Persistent Memoryがプログラミング言語に与える影響はデカそう メモリとして使うか、ストレージとして使うか選べるのは強い。

Java EE 8

JavaEE8

Reactive-API, HTTP/2, JSON java binding...

開発は、java.netから　Githubに移行。

Eclipse Enterprise for Java (EE4J)

おそすぎる進化。オープンでNimbleな開発をする必要があるとOracle&コミュニティで判断が出た。
そしてEclipse Fundactionに移管される。

EE4Jは移管のプロジェクト名らしい。
別個に名前がつくのか、このままブランド名採用されるのかは、まだ未定。

EE4Jは、まだ始まったばかりで何も決まってない。

移管することのメリット

  • 開発プロセスの透明化
  • 多くの人に参加してもらう。オラクルも１ベンダーとして参加する。

Microservices Topic & Approach

話題・取り組み事例

最初はモノリス。サービスの拡大でスケール必要になると、結果としてマイクロサービスアーキテクチャになった。
組織と文化は、後追いで対応。数年がかりで継続してやらないと難しい。
技術的なことより、組織と文化をどう変えていくかが焦点になる。
コンウェイの法則が注目されている。
自主性や自立性を重視する考え方が必要。

サービスが連携しなうので、破壊的変更は、手続きをする。
それ以外なら、ある程度の裁量を与えてサービスを拡張させていく。
やるなら、同期＜非同期を推奨。

重要ワード

今のマイクロサービスの流れ

議論は、フレームワークやライブラリの開発ではなく、サービスという部品の連携をどうするかに考えがシフトしていっている。

マイクロサービスで話題になること

同期処理

同期処理は呼び出しだと、エラー制御が難しく、インタフェースがもろくなりやすい。　　

結果整合性

ことなるデータストアの整合性は、いつかは一致するという考え。
これを許容することがマイクロサービスにとって重要みたいな話になっているらしい

Event sourcing

データストアをイベント記録に使う。
記録をためていくだけ。追加だけで、更新はしない。

CQRS

登録処理と参照処理は、必ずサービスを分断しましょうって考え。

まとめ

マイクロサービスは、サービス拡張の結果なるもの。 モノリスが悪ではない。最初から分割して作るは、ドメイン境界を見極める必要がある。 ただ、それは非常に難しい。初期から要らぬところで悩む必要がある。

Fn Project

Function実行環境。
Fnの告知な気がする。

あんまり内容は覚えてない。。。

Community&総括

日本と世界でIT業界の男女比が違いすぎる。。。
残業ありきだから、女性がこないのだろうか？
逆に考えるんだ、残業しちゃっても誰もクレームつけないんだぜって。
残業代貰い放題！

Java女子部って５００人もいるのか。。。
１０分の一くらいかと思ってた。。。

今後やるべきタスク

  • Migration Guideの査読
  • 今後のリリース内容を収集・確認する方法を確立する
  • Persistent Memoryについて、情報収集・シミュレータを試してみる
  • Fn Projectの情報収集

しまったぁぁぁぁ！！！！

リリースを理解して満足してしまったから、すっかり忘れていた。
Java10とかの呼称がなくなったから、OracleのJava認定試験がどうなるのか、聞くのを忘れてた。。。

Javaの認定試験はすごく大事。 もってると会社で威張れて給料が高くなるから！
どうなるんだろう？
JJUG CCC 2017で聞けるのかな？
機会があったら質問しておこう。。。