orangeitems’s diary

クラウドではたらくエンジニアの日々の感想です。

OpenJDK11のLTS(長期サポート)実現をOracleが支援する方向で調整

f:id:orangeitems:20180506193901p:plain

 

概要

Oracle社のJavaプラットフォーム部門による製品管理ブログにて、「Java SEリリース間隔の修正とFAQ」という文書を、2018/5/3に製品管理シニアディレクター、ドナルド・スミスさんがアップしました。

Update and FAQ on the Java SE Release Cadence | Oracle Java Platform Group, Product Management Blog

Javaのサポートポリシー変更については、日本のみならず世界において大変話題になっており、ある程度の火消しを狙った文書と思われます。特に、OpenJDKのLTS(Long Term Support、長期サポート)についての記述がありますので強調して紹介しておきます。結論から言うと、OpenJDK11のLTS化に大きな望みをつなぐ記載となっています。

 

日本語翻訳(原文:Update and FAQ on the Java SE Release Cadence)

※本文は個人的に翻訳したものです。正確な情報は原文をご確認ください。誤訳部分があれば随時更新します。

 

2018年5月3日(木曜日)
Java SEリリースケイデンス(間隔)に関するアップデートとよくある質問
投稿者:Donald Smith | Sr.製品管理ディレクター

Java SE 9の作業が2017年の早い段階で終了したため、一部のOpenJDKコミュニティの貢献者は、新しい機能をよりタイムリーに反映させるために、Java SEプラットフォームとJDKをより早いペースで進化させる方法の検討を始めました。 JCPワーキンググループが設立され、Java Community Processが変化に対応する方法を検討しました。主な貢献者の間でのさらなる議論の後、計画が提案され、並行して、Oracleは商用Java SE製品の計画を発表しました [1]。

その後、OpenJDKコミュニティは、Oracleのリーダーシップのもとに、Java SE 9、Java SE 10、Java SE 11のアーリーアクセスビルド、また、調整されスケジュールされた複数のセキュリティアップデートを提供しています。OpenJDK 脆弱性グループが結成されました。 Java SE 10で小さな新しい言語機能が追加されたことは、新しいリリースケイデンス(間隔)が、実装だけでなくJCPの仕様作業でも機能することを示しています。

言い換えれば、新しいケイデンス(間隔)は、私たちが長年にわたって慣れ親しんできた用語やプロセスに新しい語彙や意味を導入します。簡単に理解できる新機能の予測できるリリーススケジュールのメリットは、明確に、エコシステムの中の最も大きいプロジェクトのいくつかへの努力と同じ価値を持ちます。この傾向は、Java SEエコシステムの他の部分でも発生しています。たとえば、Eclipseは、年次「リリーストレイン」があり、Wildflyは四半期ごとのリリースモデルに移行しています。

このブログのエントリーは、この数ヶ月間に尋ねられた共通の質問のいくつかに対処します。

 

Q1:確実に誰もが6ヶ月ごとのメジャーリリースを採用するとは想像できませんよね?

それ以上の「メジャーリリース」はありません。それは今やレガシーな言葉です。代わりに、「機能リリース」の安定した流れがあります。これは、バージョン管理上の新しい取り組みを除いて過去にいくつのリリースが行われたことと一致しています。例えば、Java 8は2014年3月にリリースされました。機能リリースである8u20は、ほぼ半年後の8月にリリースされました。 次の機能リリースである8u40はその6ヶ月後にリリースされました。

したがって、以前と同様に、6か月ごとに「機能リリース」の取り込みを期待しています。

Java 9→10→11は8→8u20→8u40の方が、7→8→9よりも近いのです。はじめのうちは3年ごとのメジャーリリースに慣れているため、その大きな変化がもたらす巨大な影響を精神的に持つことで、恐怖感が生まれるでしょう。6ヶ月のリズムはそうではありません。FAQの後半で、これについてのより具体的な証拠を提供します。

 

Q2:新しいリリースが基本的に6ヶ月の寿命である場合、毎回メジャーリリース番号をカウントアップするのはなぜですか?なぜそれを9u20、9u40などと呼んでいないのですか?

いくつかのJCPプロセスを合理化することで、「メジャーリリース」のために何年も待たずに、新しいクラスライブラリ、JVM、ローカル変数型推論などの言語機能をわずか6ヶ月で導入することが可能になりました。 2年ごとに仕様が大きく変更されるため、導入の準備が整い次第、より実用的に安定した流れで導入することができます。

 

Q3:仕様の変更は危険に思えます。更新によりツールのエコシステムが阻害されるのではないでしょうか。

いくつかのツールは8→9に移行するのに苦労していますが、その移行を行った人がほぼ一晩で9→10になることができます。

Java 10がリリースされたとき、主要な IDE はすべて、数日で新しいローカル変数型推論機能を含むJava 10をサポートしていました。GradleやLuceneのような人気のあるプロジェクトは、すぐに正式なサポートを追加しました。UbuntuやSUSE Linux Enterprise Serverなどの有名なLinuxディストリビューションでは、最新のOpenJDKをプラットフォーム上のデフォルトのJRE / JDKにするために積極的に調整されています。 Elasticsearchは、新機能の恩恵を受けるために、できるだけ早くLTSリリースと非LTSリリースの両方と互換性があることを計画しています。これらは、他のプロジェクトや製品が6ヶ月のリズムに追いついている例のほんの一部です。

この新しいケイデンス(間隔)は、ツールベンダーにとってより管理しやすく、予測可能にします。さらに、将来の開発者は、OpenJDK Project Valhallaの最小値型や、OpenJDK Project ZGCのZ Garbage Collectorなどの新しい機能を、使い慣れたオープンソースライセンスで利用可能なアーリーアクセスビルドを使って研究することができます。

 

Q4:新しいバージョン「X + 1」がわずか6ヶ月間先にあるのに、バージョンXにアップデートする目的は何ですか?

最新のOracle JDKビルドとOracleのOpenJDKビルドは、開発者によって毎月何百万回もダウンロードされます。Java 9の最新リリースは、Java 7およびJava 8よりもはるかに高速にダウンロードされています。たとえば、この文書の時点でのJDK 10のダウンロード数は、JDK 8の更新版数を5倍上回ります。

新しいリリースケイデンスの強力な理解は印象的です。一般的なIDEや他のツールベンダーがJava 10のサポートを迅速に採用して利用できるようになることは非常に奨励されています。

 

Q5:私はまだ確信できていません。Java 9を採用するのはチャレンジです。そのため、10や11もそうなると思います。

多くのJava SE開発者とユーザーは、新しい「メジャーバージョン」を採用する前にいくつかのアップデートを歴史的に待っていました。これは、「メジャー」リリースに数多くの主要な仕様変更機能が含まれていても、このケースは6ヶ月のリリースで進行しています。これは、Java SE 9以降のケースではありません。

たとえば、Java SE 9のリリースでは、Java SE 8の上に約19,000のソースコードの変更が組み込まれていました.Java 9とJava 10の間では2,700通りの変更しかありませんでした。Java 8とJava 8u40の変更とほぼ同じです。したがって、Java SE 9はJava SE 8と比較して「メジャー」なアップグレードですが、Java SE 10はJava SE 9のシンプルな機能更新版です。

 

Q6:X + 1リリースの移行がスムーズになることを、どのように確信できますか?どのくらいの時間がかかるのですか?

アーリーアクセスビルドは、Oracle独自のOpenJDKビルドを含めて、以前よりダウンロードして試すことは簡単です。OracleのOpenJDK アーリーアクセスビルドをビルド・テスト・システムで使用することを開発者に推奨します。そのため、問題が早期に発見される可能性があります。

機能リリースの最終更新と次の機能リリースのセキュリティ更新プログラムの間には3ヶ月があります。この間に移行することを強くお勧めします。新機能リリースと次回の予定されているセキュリティ更新では約1ヶ月が経過しています。たとえば、Java 9.0.4は2018年1月に、Java 10.0.0は2018年3月に、10.0.1は2018年4月にリリースされました。Java 10.0.1リリース以降、Java 9.0.4またはJava 10.0.0の使用はお勧めしません。ただし、JDK 10のアーリーアクセスビルドは、10.0.1アップデートリリースの6ヶ月以上前、2017年11月から定期的に公開されています。

これは、フィーチャーリリースとそれに続くセキュリティーアップデートの間に4〜6週間あった過去のリリースと一致しています。たとえば、2015年3月初旬に8u40がリリースされました。予定されていたセキュリティアップデート8u45が2015年4月14日にリリースされました。(注:原文では2014とありますが2015の誤りだと思います。)。

 

Q7:わかりましたが、私は新しい機能を望んでいません。私は本番環境のシステムを持っており、安定性、パフォーマンス、およびセキュリティの更新のみを望んでいます。私は何をしますか?

Oracleでは、2018年9月のJava SE 11以降の「長期サポート」(LTS)リリースとして、3年ごとにリリースを指定する予定です。Java SE 9 のリリースはJava 10のリリースで終了しました。 Java 10はJava 11のリリースで同様に動作しますが、Java 11は少なくとも8年間はOracleの商用サポートを受ける予定です。

Java 6とJava 7(そして2019年にはJava 8と思われる)でほぼ10年の間に起こったように、OracleがOpenJDKの特定のリリースシリーズにソースコードの変更を寄付しなくなった後は、顧客のニーズに集中することができます。OpenJDKコミュニティの他の有資格者は、リリースシリーズの継続的なメンテナンスを進める可能性があります。彼らはOpenJDKコミュニティ標準に従って、選択した限り、Oracleやその他の人々がまだ維持している後のリリースから関連する変更をバックポート(修正)します。例えば、JDK 6の場合、Sunは2008年にプロジェクトを確立し、Oracleは2013年までこれを維持し続けました。その後、他のメンテナナンス担当は、後のリリースからの更新をバックポートすることでプロジェクトの作業を続けました。

Oracleは、JDKアップデート・プロジェクト内で確立されたプロセスを提供するとともに、新しいメンテナンス担当が新しい役割を果たし、少なくとも脆弱性グループであることを保証するために、OpenJDKコミュニティの移行をサポートしています。(注:この文が最も重要です。)

 

Q8:Java SE 8では何が起こっていますか?

Java SE 8は、従来のバージョン管理とリリースのケイデンス(間隔)モデルの終わりです。Java 9は新しい始まりでした。

Oracle JDKの場合、Java 8はJava 7およびJava 6とまったく同じ移行プロセスを実行していますが、例外はあります。まず、新しいリリース・モデルに慣れるために、Oracle JDKのパブリック・アップデートを2019年に商用生産用に、少なくとも2020年末にデスクトップ用に拡張しました。2つ目は、Java 6 - > 7およびJava 7 - 8の場合と同様に、Oracle JDKをOracleのOpenJDKビルドと互換性を持たせるための取り組みを発表しました。あなたがまだそれをしていないならば、我々は10に移動し、新しいリリーストレインに乗ることを提案するでしょう。最後に、Javaクライアント(アプレットとWeb Startを含む)のロードマップに関する詳細情報を掲載しました。

OpenJDKのフロントでは、Oracle は 2019年1月までJDK 8 Updatesプロジェクトを継続してリードし、貢献する予定です。その前に、新しいメンテナの要請が行われます(詳細は前のQを参照してください) 。

 

Q9:私はOracleの顧客ですが、どのように影響を受けますか?

Java SEの依存関係を持つOracle製品内でJava SEを使用する場合は、対象となります。このMy Oracle Supportノートで詳細を確認してください。

2018年5月4日編集 質問に番号を追加し、Q8のJavaアプレットとWeb Startのロードマップへの参照を追加しました。

 

脚注:

[1] - ; Oracleがバイナリとビルドのために発表した計画のためのtldr - (a)Oracle JDKの以前にクローズされたすべてのソース・ビットをOpenJDKに移動する(b)GPLv2 + CPEの下でOpenJDKバイナリを公開する、(c) Oracle JDKとOpenJDKのバイナリが交換可能なようなスムーズな移行

 

補足

Oracle自身が、Q7において、OpenJDKは、Oracle JDKのバックポートつまり修正点の修正を移行しサポートし続けるように支援することを明言しているように読めます。

確実にOpenJDKのコミュニティーが正式に発表したわけではないので速報ベースとはなりますが、Oracleの公式ブログの中でこの発言があったことは、Java関係者としてもまずは安心できるニュースではないでしょうか。