Javaの新リリースモデルについて＠関ジャバ(2018/07/20)

# Javaのリリースモデルが変わりました
[関ジャバ '18 7月度 新リリースモデル関連&JCP [大阪]](https://kanjava.connpass.com/event/93008/)にて、Javaの新リリースモデルについてのセッションがあったので参加してきました。Javaのリリースモデルについては[良い記事](https://qiita.com/nowokay/items/edb5c5df4dbfc4a99ffb)が色々アップされているけど、自分の備忘録としてまとめておきます。

# 新しいJDKリリースモデル解説(伊藤 敬さん)
[資料](https://www.slideshare.net/oracle4engineer/jdk-ver20)がアップされています。
## 無償のJavaはなくならない！
## これまで
- 従来(JDK8まで)はOpenJDKコミュニティがソース開発。バイナリ提供なし。Oracleルがビルドしてバイナリを生成していた。この時に、その際にJAvaFXやインストーラなど(Javaの標準仕様外)も梱包されていた。
提供形態はJDK/JRE。ライセンスはBCL（バイナリコードライセンス）。社内でのコピー/配布はOKだけど、社外へのコピー/配布はNG。
- 実はライブラリやツール類(コンパイラなど)は同一。
    - これが意外だった。てっきり違うものかと思ってた・・・
- Oracleはセキュリティアップデートは年４回実施し、合わせてバグフィックスも同梱。
- OpenJDKは独自のアップデートしていたので、OracleJDKと完全に一致したリリースはしていない。

## JDKリリースに対するニーズ
- 短期間のバージョンアップ
- １バージョンを長期に渡って使いたい
    - ユーザー企業からのニーズ
- ITトレンドやインフラ進化への適応
- 安定した周期でのリリース
    - JDK９は２年位延期した・・・
    - 6→7は4年７ヶ月、7→8は2年８ヶ月、8→9は3年６ヶ月
- 期間が長くなると新規搭載する機能が多くなる。
    - 8-9は91機能(jigsawなど)も・・・
    - もっと早く新機能をリリースしてほしいという開発者のニーズ

## 早いリリース/長いサポートを両立するための解決をJava9以降で採用
- Oracleは２パターンのリリースを提供
    - OpenJDKのままのバイナリを無償提供
    - インストーラのみを包含したバイナリをOracleJDKとして提供。こちらは有償。
    - 違いはインストーラの有無のみ。これまでOracleJDKにのみあったJFR/JMCはJDK11からはOpenJDKの仕様として包含される。
- OpenJDKは６ヶ月、OracleJDKは３年でリリース
    - OpenJDKでは新機能を早く利用することができる
    - OracleJDKではバージョン固定のニーズに対応(LTS)
- アップデートは同周期で適用される。年４回。セキュリティのアップデートも適用できるので、OpenJDKも商用利用できるとしている。
- サポートについて
    - OpenJDKはコミュニティによる無償サポート。
    - OracleJDKはオラクルによる有償サポート。ただし、開発・テスト・試作などの用途であれば無償で利用できるようになる(予定)。
        - WebLogicとかと同じようなかんじになる
- 今後はOracleJDK/OpenJDKはライフサイクルをともにするが、OracleJDKは３年に１回、８年サポートのLTS(アップデート・リリース用)が提供される
    - LTSは５年間のオーバーラップが発生するようになる。
- リリースは年６回発生する。
    - バージョンアップリリースは３月と９月で固定。新機能が追加される。
    - アップデートリリースは1,4,7,10で固定。対象は脆弱性対策とバグFIX。新機能追加はなし。
- リリース情報はOpenJDKから入手する。
    - 非推奨/削除対象はリリースノートに記載されている。
    - 非推奨になったあと、最速次回のバージョンアップで削除される可能性がある。非推奨→削除が１年で済んでしまう可能性もある。
- 機能追加が間に合わなければ次回リリースへ。

## どうしたらいいのか
- Java9,10は商用利用しない方が良い。
    - 11がLTSなので、8→11のアップデートが推奨。11は2026年9月までのサポート。
    - 11を逃すと、その次は17LTSまで商用推奨のバージョンはとぶ。
- Oracle以外のJDKという選択肢もある
- 古いJDKは引き続き入手可能。OracleJDK/OpenJDK両方入手可能。
- Java SE Subscription
    - 有償サポート
    - ライセンス、サポート、商用機能が提供される。
    - デスクトップ版とサーバ版は料金体系が異なる。
    - まだ日本円の料金は出ていないけど、もうすぐ発表される。
 
# これからのJCPについてー活動内容のアップデートー(Naoko Hamamotoさん)
~~今回の資料はまだアップされていないようです。しかし、[過去の資料](https://jcp.org/aboutJava/communityprocess/JCP_Overview_Java_Women_Japan_July2017.pdf)をネットで見付けました。内容もだいたい同じな気がする。~~
[資料](https://jcp.org/aboutJava/communityprocess/JCP_Japan_JUG_visit_July2018.pdf)がアップされています。
## JCPに参加しよう！
## JCPとは・・・
- JavaCommunityProcess
- JSRを通じてJava技術規格を開発、改訂を実施。
## JSRとは・・・
- 企画仕様の提案。これまでに380以上。
- JSRは投票によって進行する。少なければrejectされる。
- ExecutiveCommittee
    - 個人もいる。企業もいる。
    - ECはJSRを次に進めるかの権限を持っているが、企業間の利害に支配されないように色んなバックグランドの人たちが参加している。
    - 辞任によって席があいたら選挙で補充される
- 日本のJCPメンバーも多数。関ジャバもメンバー。
- メンバーは南極と北極以外であればあらゆるところに居る！！

## こらからどうなっていく
- 数年前から透明化に努めており、活動をオープンに。
    - 議事録は公開されている。
    - ECへの質問会の録音も公開されている。
- ECを１つに。
    - 以前はSE/EEとMEで別れていた。
- 参加数増加の取り組み
    - 無料のメンバーシップが追加
    - 紙面ではなく、電子署名で参加可能になった
    - 参入障壁を下げている
- ECにAssociateSeatsを追加したので、個人席が確保されている。
- 登録は英語で。日本語は文字化けする・・・
    - 登録にあたっては、日本語でのサポートも可。
    - まずはAssociateから参加しよう！
- 今まではまずはスペックを書いていたけど、コードファーストで開発できるようにJSR387を提案

## Q&A
- メンバーになりたい場合、審査はある？
    - 日本に住んでいれば審査はない
- 毎月のミーティングは参加必須？
    - ミーティング参加が必須なのはECのみ
    - 年１回の選挙のみだけは参加してほしい
    - 参加したい活動に参加して、自由にJavaをサポートしてほしい

# いかにJavaのバージョンアップと付き合うべきか(谷本 心さん)
[資料](https://docs.google.com/presentation/d/1Q2xaFjJQwinzfAnnNVPNIiB-rfZeld2w_nIZ_y4oMlQ/edit)がアップされています。
## 可能な限りバージョンアップには追従しよう
## どのバージョンを使ってる？
- Java9は既にEOL。
- １年前：Javaは歩みが遅い。
    - サイクルの遅さが弱点になりかねなかった。
- 今：Javaの歩みは早すぎる
    - ライフサイクルが早くなった
- Javaのライフサイクルの変更については、有償化とか無償化とかが本質ではなく、アップデートのスピードが早くなったのが大切なこと。
    - 世界のみんなが戸惑っている！
    - ライフサイクルが早くなったんなら追従すれば良いけど、簡単ではない

## なぜ追従すべき？
- セキュリティ問題への対応
    - 昔は枯れるまで待たれていたけど、最近は攻撃者のスピードがあがってきた。
    - 一般周知されている脆弱性は放置したらダメ。パッチはすぐあてるべき。
    - 枯れるまで待つなんて論外。
- 技術的な追従
    - アップデートをかけ続けることで、モダンに追従できる。
    - そのために、マイクロサービス化やテスト自動化に取り組む必要があるため、対象環境が副作用的に良くなる。
    - Javaは後方互換生が高いので、アップデートによって何かが動かなくなる可能性は低い。安心してアップデートがかけられる。
        - JavaFXとかなくなるものもあるけどね・・・ 

## アップデートについて
- 再テストについて
    - テストはするしかない。
    - セキュリティリスクを放置することはできないし、やるしかない。
    - バージョンアップ時に合わせて機能追加を計画しておけば予算確保もしやすいのでは？
    - 可能な限りテスト自動化させて、手動テストは最小限に。
- 周辺ライブラリやフレームワークの対応
    - Spring1.xはJava9から対応していない。
    - Javaのバージョンが上がったらライブラリ/FWも追従させないといけない。
    - ライブラリ/FWのバージョンによっては、使用するバージョンが自動的に縛られる場合も
    - lombokはJava9以降のサポートが遅れているので、逆に挙げられないパターンも
- 新しい文法への対応
    - 統一感
      - IDEで自動変換？
      - 新旧混在はツライ
    - 互換性
      - 一部だけバージョンが進んでしまうと、相互の関連がうまくいかなくなることも
    - スキル
      - 新しい文法のベストプラクティスは？

## バージョンアップ戦略
- JDKの選択肢
    - OpenJDK
    - OracleJDK
    - AdoptOpenJDK
        - 独自ビルドしたOpenJDKを提供 
        - IBMやMicrosoftなどがスポンサー.
        - 4年間のLTS
    - RedHatのJDK
        - RedHatがビルドしたOpenJDK 
        - 正式発表はないけど、それなりのLTSが提供されると思われる

- 選択肢
    - ①最新に追従
    - ②LTSに追従
    - ③追従しない
    - これまでは②③の選択肢しかなかったが、今回のリリースモデルの変更では①という選択肢が増えた。マイナスの影響はなく、単純に選択肢が増えた
- 現実路線は②だけど、是非①に挑戦してほしい

# まとめ
『Javaが有償になる』という話が先行して「Java終わったな」とか言う人が弊社内にも居たりしました。
でもでも、トラブル時のサポートなんて(幸いに)受けたことなんて無いし、Javaに対してはお金払ってないかもしれないけど高価なAPサーバで実質的には有償でJava使っているようなもんだし、本当に必要なのは脆弱性対策のみ。その脆弱性対応については有償/無償変わらず提供されるのだから何のマイナスも無い、というのが結論。
ただし、無償のJavaを使うのであればOpenJDKではなくAdoptOpenJDKを使いましょう。