[Java] Update and FAQ on the Java SE Release Cadence

原文はこちら。
https://blogs.oracle.com/java-platform-group/update-and-faq-on-the-java-se-release-cadence

---

Java SE 9の作業が2017年の早い段階で終了したため、OpenJDKコミュニティのコントリビュータから、Java SEプラットフォームとJDKをより早い段階で進化させて機能をよりタイムリーに配信できる方法があるだろうかという疑問が投げかけられました。Java Community Processがそのような変化に対応する方法を検討するため、JCPワーキンググループが設立されました。

17 February 2017 OpenJDK Working Group Meeting Minutes
https://community.oracle.com/docs/DOC-1015451

主要なコントリビュータの間でのさらなる議論の後、計画が提案され、並行して、Oracleは商用Java SE製品の計画を発表しました[1]。

Moving Java Forward Faster
https://mreinhold.org/blog/forward-faster
Faster and Easier Use and Redistribution of Java SE
https://blogs.oracle.com/java-platform-group/faster-and-easier-use-and-redistribution-of-java-se
https://orablogs-jp.blogspot.jp/2017/09/faster-and-easier-use-and.html

その後数ヶ月の短期間で、OpenJDKコミュニティは、Oracleのリーダーシップの下、Java SE 9、Java SE 10、Java SE 11の早期アクセスビルドだけでなく、調整されたスケジュールでセキュリティアップデートを複数提供してきました。

JDK 9
http://openjdk.java.net/projects/jdk9/
JDK 10
http://openjdk.java.net/projects/jdk/10/
JDK 11
http://openjdk.java.net/projects/jdk/11/

OpenJDK Vulnerability Groupが結成されました。

OpenJDK Vulnerability Group
http://openjdk.java.net/groups/vulnerability/

Java SE 10では、小さな新しい言語機能が追加されました。

JEP 286: Local-Variable Type Inference
http://openjdk.java.net/jeps/286

これは、新しいケイデンスが、実装だけでなくJCPの仕様作業でも機能していることを示しています。

ということで、新しいケイデンスは、私たちが長年にわたって慣れ親しんできた用語やプロセスに新しいイディオムや意味を導入します。明らかに、容易に新機能を取り込めるという、予測可能なリリーススケジュールの利点は、エコシステムの最大のプロジェクトに対する成果に値します。この傾向は、Java SEエコシステムの他の部分でも発生しています。たとえば、Eclipseでは長年にわたって年1回のrelease trainがありますし、Wildflyは四半期ごとのリリースモデルに移行しています。

Simultaneous Release
https://wiki.eclipse.org/Simultaneous_Release
[wildfly-dev] WildFly 12 Plans, EE8, and Move to Quarterly Iterative Releases
http://lists.jboss.org/pipermail/wildfly-dev/2017-December/006250.html

このブログエントリでは、この数ヶ月間に尋ねられたよくある質問にお答えします。

Q: Surely you can’t expect everyone to adopt major releases every six months?! （誰も6ヶ月ごとにメジャーリリースを採用するとは思いませんが？）

正確な意味では、もう「メジャーリリース」はありません。その用語は古いものです。その代わりに、feature releaseという安定した流れがあります。これは、バージョン管理の新しい取り組みを除いて、過去のリリース回数に一致しています。例えば、Java 8は2014年3月にリリースされました。feature releaseである8u20は、8月のほぼ半年後にリリースされました。次のfeature releaseである8u40は、その後6ヶ月後にリリースされました。

8u20 Update Release Notes
http://www.oracle.com/technetwork/java/javase/8u20-relnotes-2257729.html
8u40 Update Release Notes
http://www.oracle.com/technetwork/java/javase/8u40-relnotes-2389089.html

したがって、以前と同様に、6か月ごとにfeature releaseの取り込みを期待しています。

Java 9→10→11は、7→8→9よりも8→8u20→8u40の方が近いものです。3年ごとにメジャーリリースに慣れていて、そうした大きな変化の巨大な影響のメンタルモデルを持っているときは、当初は怖いと感じるでしょう。6ヶ月のリズムはそうではありません。FAQの後半で、これについてより具体的な証拠をご紹介します。

Q: If the new releases are basically the long standing six-month cadence, why rev the major release number each time?  Why not just call it 9u20, 9u40, etc.? （新しいリリースが基本的に長年の6ヶ月サイクルである場合、毎回メジャーリリース番号を上げるのはなぜですか？なぜ9u20、9u40などと呼ばないのですか？）

JCPプロセスを合理化することで、major releaseのために何年も待つ必要はなくなり、新しいクラスライブラリ、JVM機能やローカル変数型推論などの言語機能をわずか6ヶ月で導入することが可能になりました。

JEP 286: Local-Variable Type Inference
http://openjdk.java.net/jeps/286

2年ごとに数多くの仕様変更をリリースするのではなく、導入の準備が整い次第、より実用的に安定した流れに導入できます。

Q: Spec changes sound dangerous and they’ll inhibit tools ecosystem from updating, right? （仕様変更は危険に感じます。ツールのエコシステムがアップデートされなくなるのではないでしょうか？）

いくつかのツールは8→9への移行に苦労していますが、その移行が済んでいればほぼ一晩で9→10に移行できました。

Java 10がリリースされたとき、主要なIDEはすべて、数日で新しいローカル変数型推論機能を含むJava 10をサポートしました。

Webinar: IntelliJ IDEA and Java 10
https://blog.jetbrains.com/idea/2018/04/webinar-intellij-idea-and-java-10/
The Eclipse Project Downloads
http://download.eclipse.org/eclipse/downloads/#Latest_Release
JDK 10 (March 2018) - Apache NetBeans 9.0 New and Noteworthy
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75971001

GradleやLuceneのような人気のあるプロジェクトは、すぐに正式なサポートを追加しました。

Gradle Release Notes
https://docs.gradle.org/4.7/release-notes.html
Apache Lucene
https://lucene.apache.org/

UbuntuやSUSE Linux Enterprise Serverなどの人気のあるLinuxディストリビューションでは、最新のOpenJDKをプラットフォーム上のデフォルトのJRE/JDKにするために積極的に調整していました。

OpenJDK SRU exception
https://lists.ubuntu.com/archives/ubuntu-release/2018-February/004275.html
SUSE Linux Enterprise Server 15 GA Release Notes
Supported Java Versions
https://www.suse.com/releasenotes/x86_64/SUSE-SLES/15/#TechInfo.Java

Elasticsearchは、新機能の恩恵を受けるために、できるだけ早くLTSリリースと非LTSリリースの両方と互換性を持たせることを計画しています。

Elasticsearch: Java 9 and Beyond!
https://www.elastic.co/blog/elasticsearch-java-9-and-beyond

これらは、他のプロジェクトや製品が6ヶ月のリズムに追随している例のほんの一部です。

この新しいリリースサイクルは、ツールベンダーにとってより管理しやすく、予測可能にします。今では小規模なアップデートの安定した流れがあります。さらに、将来を見越した開発者は、OpenJDK Project Valhallaのminimal value typeや、OpenJDK Project ZGCのZ Garbage Collector（ZGC）などの新しい機能を、使い慣れたオープンソースライセンスで利用可能な早期アクセスビルドを使って調べることができます。

Project Valhalla "Minimal Value Types" Early-Access Builds
http://jdk.java.net/valhalla/
Project ZGC "The Z Garbage Collector" Early-Access Builds
http://jdk.java.net/zgc/

Q: Why would anyone update to version X when a new release X+1 is only six-months away? （新しいリリースX+1がわずか6ヶ月先にリリースされるのに、バージョンXにアップデートするのはなぜですか？）

最新のOracle JDKビルドとOracleのOpenJDKビルドを、開発者は毎月何百万回もダウンロードしています。

Java SE Downloads
http://www.oracle.com/technetwork/java/javase/downloads/index.html
Java Development Kit builds, from Oracle
http://jdk.java.net/

JDK 9、10を含め、各feature releaseでJDKダウンロード件数は着実に増加しています。Java 10の最新リリースはJava 7やJava 8よりもはるかに速いペースでダウンロードされています。例えば、このエントリ記述の時点でのJDK 10のダウンロード数は、JDK 8アップデートのダウンロード件数を5倍上回ります。

新しいリリースサイクルの速い普及は印象的です。人気のあるIDEや他のツールベンダーがJava 10を迅速に採用してJava 10のサポートを利用できるようになるのを見て、非常に力づけられています。

Q: I’m still not convinced.  Java 9 was a challenge to adopt, so that means 10 and 11 will be, too. （私はまだ納得していません。Java 9は採用が難しかったのです。10と11も同じだと考えています。）

多くのJava SE開発者とユーザーは、これまで新しいmajor versionを採用する前にアップデートを待っていました。これは、major releaseに数多くの主要な仕様変更の機能がある場合に想定されるものでしたが、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 9はJava SE 9のシンプルな機能アップデートです。

Q: How can I be confident that the X+1 release transition will be smooth?  How much time is there to transition? （X+1リリースの移行がスムーズになることは、どうすればわかりますか？移行にどのくらいの時間が必要ですか？）

早期アクセスビルドは、Oracle独自のOpenJDKビルドを含めて、以前よりダウンロードや試用が簡単です。

JDK 11 Early-Access Builds
http://jdk.java.net/11/

OracleのOpenJDK早期アクセスビルドをビルドテストシステムで使用することを開発者に推奨します。そうすれば、問題が早期に発見される可能性があります。

feature releaseの最終更新から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の使用はお勧めしません。ですが、1ヶ月、もしくはテスト開始まで3ヶ月待つ必要はありません。10.0.1のアップデートリリースが出る6ヶ月以上前から、JDK 10の早期アクセスビルドは2017年11月から定期的に公開されているからです。

Java Development Kit builds, from Oracle
http://jdk.java.net/

これは、feature releaseとそれに続くセキュリティアップデートの間に4〜6週間あるという、これまでのfeature releaseと一致しています。例えば、2015年3月初旬に8u40がリリースされ、後に続くセキュリティアップデートの8u45は2015年4月14日にリリースされました。

Q: Ok, but I don’t want new features.  I have a system in production and just want stability, performance and security updates only.  What do I do? （わかりましたが、本番環境のシステムがあるので、新しい機能ではなく、安定性、パフォーマンス、およびセキュリティの更新のみを望んでいます。どうすればいいですか？）

Oracleでは、2018年9月のJava SE 11から、「長期サポート」（LTS）リリースとして、3年ごとにリリースを指定する予定です。Java SE 9のリリースはJava 10のリリースでEnd of Lifeを迎え、Java 10もJava 11のリリースで同様にEnd of Lifeを迎えますが、Java 11は少なくとも8年間はOracleの商用サポートを提供する予定です。

Oracle Java SE Support Roadmap
http://www.oracle.com/technetwork/java/eol-135779.html

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

Oracleは、JDK Updates Project内で確立されたプロセスを提供するとともに、新しい役割、そして大事なことを言い忘れていましたがVulnerability Groupの役割に慣れるために新しいメンテナーへの支援を提供することで、OpenJDK Communityでこうした移行をサポートしています。

[9u Communication] End of maintenance timeframe & invitation for prospective new maintainers
http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2018-February/000087.html

Q: What’s happening with Java SE 8? （Java SE 8はどうなるの？）

Java SE 8は、従来のバージョン管理とリリースサイクルモデルの最終で、Java 9は新たなスタートでした。

Oracle JDKの場合、Java 8はJava 7やJava 6と全く同じ移行プロセスを辿りますが、いくつかの例外があります。まず、新しいリリース・モデルに慣れるための猶予時間を増やすために、Oracleは商用本番利用用途向けに2019年1月、個々のデスクトップ向けに少なくとも2020年末までにOracle JDKのパブリック・アップデートを拡張しました。2つ目は、Java 6→7およびJava 7→8の場合と同様に、次のリリースに移行したい人向けに、Oracle JDKをOracleのOpenJDKビルドと互換性を持たせるための取り組みを発表しました。あなたがまだ移行されていないならば、10に移行し、新しいリリーストレインに乗ることをご提案します。

OpenJDKの領域では、Oracleは2019年1月までJDK 8 Updatesプロジェクトを継続してリードし、貢献する予定です。その前に、（これまで10年にわたって実施されていたように）新しいメンテナの要請が行われます（詳細は前の質問をご覧ください） 。

[8u-communication] Oracle's plans to contribute to JDK 8 Updates Project in OpenJDK after Java SE 8 End of Public Updates
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2018-March/007341.html

Q: I’m an Oracle Customer, how am I affected? （Oracleの顧客にはどのような影響があるのか？）

Java SEを依存関係に持つOracle製品内で、Java SEを利用する場合には影響を受けます。詳細はMy Oracle Supportの記述をご覧ください。

Support Entitlement for Java SE When Used As Part of Another Oracle Product (Doc ID 1557737.1)
https://support.oracle.com/rs?type=doc&id=1557737.1

［脚注］

[1] Oracleがバイナリとビルドのために発表した計画は以下の通り。

1. Oracle JDKの以前の全てのクローズドソースをOpenJDKに移動する
2. GPLv2 + CPEの下でOpenJDKバイナリを公開する
3. Oracle JDKとOpenJDKのバイナリは互換性を持たせてスムーズな移行を保証する