たなかこういちの資料室

システム開発に携わる筆者があれこれ試したことや学んだことについてのまとめ

今後のJDKリリース計画について、まとめ(2018年6月時点)

 
 
 
周知の通り、JDKは半年に1回のペースでリリースされていくこととなりました。事実既にJDK9がリリースされた2017年9月の半年後、2018年3月にJDK10がリリース済みです。また無償版と有償版とでサポートの期間が変わるとのこと。
 
この状況に対する自分の課題は次の通りです。
 
(1) 無償で使いつづけるとしたら、どういうオプションがあるか?
(2) Scala等他のJVM言語へは何か影響があるだろうか?
 
(1)はもう少し具体的に言うと次の通り。
 
(1-1) 無償利用で、セキュリティパッチを出してくれる期間はどのくらいか?
(1-2) セキュリティパッチが出なくなったら、バージョンを上げる必要があるはずだが、それは容易なのか?
 
「サポート」といっても「技術問い合わせできる」などいろいろな内容がありますが、ここでは私としては「セキュリティパッチを出してくれるか?」という一点のみが気になるところです。
 
(2)は、具体的には次のようになります。
 
(2-1) (1-2)のようにJDKをバージョンアップしていったとき、Scalaとしての"サポート"が追いつくのか?
(2-2) 仮に追いつかなかったとき、何か問題があるか?
 
こちらで"サポート"とは、「JDKの当該バージョン上でのScala処理系の動作保証がオフィシャルに為されるか?」という一点です。
 
 
以降に、セミナーで学んだことを踏まえた私の理解をまとめます。(なお、本記事では、Oracle社の有償サポートの内容がどのように変わるかについては触れません。)
 
JDKのリリース年月、リリース機能数、サポート期間の、いままでとこれから
 
JDK7〜JDK9までのリリース年月、サポート期間、リリース機能数は下記の通りでした。(※ここでのサポート期間とは、無償でセキュリティパッチ提供の続く期間、の意味)
 
JDK7, 2011.7 - 2015.4, 約4年, 24機能
JDK8, 2014.3 - 2019.1, 約5年, 55機能
JDK9, 2017.9 - 2018.3, 6ヶ月, 91機能
 
まとめると、、
・長い期間空けた後、どどんと大量の新機能がリリースされる。
・セキュリティパッチは随時提供される。
・次期版リリース後1年間は旧版に対するセキュリティパッチ提供は続く。JDK8は特別に'19.1まで。
 
対して、JDK10以降のリリース年月、リリース機能数、サポート期間。
 
JDK10, 2018.3 -2018.9, 6ヶ月, 12機能(実績)
JDK11, 2018.9 -2019.3, 6ヶ月, 16機能(予定)
JDK12, 2019.3 -2019.9, 6ヶ月
 
まとめると、、
・短い期間で(半年毎)、次々と小刻みに新機能がリリースされる。
・セキュリティパッチの提供予定年月も事前にスケジュールされている。
・次期版リリース時点で、旧版に対するセキュリティパッチ提供は停止する。
 
これらより、課題(1-1)への回答が得られます。
 
今までは、
・旧版へのセキュリティパッチ提供は、新版リリース後1年続いていた。
・そもそも新版がリリースされるまでのサイクルが3年程度と長かった。
・結果として、一つのバージョンは数年サポートされた。
今後は、
・旧版へのセキュリティパッチ提供は、新版リリース時点で終了する。
・新版がリリースされるサイクルが半年に決定されている。
・結果として、一つのバージョンは半年サポートのみ。
 
Open JDKのデリバリーのポリシーが変化している
 
前節のようなリリース頻度の変更は、考えてみれば当然ながらOpen JDKのデリバリーのポリシーの変化を伴っている、ようです。
 
今までは、
次期版に対する機能上の目標を決めて、それへ向けて開発、
目標が達せられたらリリース、
というスタイルだったのが、今後は、
次期版としての目標は定めず、
所定の年月が来たら、その時点でのスナップショットを以ってリリース、
というスタイルに変わる/変わったそうです。LTS版(Long-Term Support)にターゲットを定めるようなこともしない、そうです。
 
開発実態から見ると、リリース版とは、今までは「ひとつのマイルストーンを達成した版」という意味だったが、今後は「その時点でマスターブランチにマージ済みのもののスナップショット」という意味となります。
 
一回バージョンアップでの変更量は減るだろう
 
JDK8,9とJDK10,11のリリース機能数の差異を見ても明らかですね、そりゃ半年で提供できる機能数は限られるってもんです。この点と、前節のスナップショットを以ってリリースする、という点を合わせると、JDK10以降のリリースでは、9までのリリースに比べて、実態的に機能差分は小さいと見込まれます。
 
それと、JDK9が特異的に厳しかったことがあったと思います。JDK9には以下のような非互換性があるようです。
 
- 32bit版のdrop
- jigsaw導入に伴う、JDK内部構成の変更やInternalなクラスの使用禁止化
- 一部物理的に除去されたpackage
 
このような後方互換のない変更は今までのJavaには無かったことです。多分Java史上初の出来事に思います。元来Javaは後方互換性の維持に注力して来ました。今後も(Javaの利用環境を鑑みる限り)基本的にはそうでしょう。今後の半年サイクルのリリースで毎度毎度、JDK9ほど後方互換のない変更が為されるかもしれないという心配は不要でしょう。
 
以上より、課題(1-2)の回答としては、JDK9への移行が特異的に難しかったが通常は容易、と言ってよいでしょう。
 
Scala側はどうなのか?
 
このJJUGイベントを踏まえて識者から一連のTweetがありました。これを参照しましょう。要点は以下のようになるでしょうか。
 
・Scala等(Java以外の)JVM言語は、JVMに変更があったら大きく影響を受けるが、「Java言語」の言語仕様やJDKのAPIセットに変更があっても大きくは影響は受けない。
・JVMの新しい機能を使った方がJVM言語としてパフォーマンスが上がるとか、バイナリ互換性が高まるとか、JVM言語としてのメリットがない限り、その新機能を使っていくというインセンティブはない。
・Javaは後方互換を原則維持するはずなので、JVM言語のコンパイラーが、JVMの古い機能や仕様に基づくバイナリーを吐き出し続けても原則問題ないはず。
 
公式のドキュメントより、"JDK COMPATIBILITY"をみてみましょう。JDK7,8,9,10に対するScalaの対応バージョンが示されています。JDK9のjigsaw導入に伴う内部クラス使用禁止問題にヒットしたようで、そのfixがなされたようです。他、CIの体制は整えていることなどが記されています。
 
課題(2-1)に対しては、CIの体制は整えていて、(JDK10までにおいては)追いついている、
課題(2-2)に対しては、識者によるTweetにある通り、JDK自体に非互換性が導入されない限り問題なく使えるはず(※JDK9には非互換性が導入された)、
という回答となるでしょうか。
 
◆以上