翻訳者から

最近、Javaの世界でいくつかの重要なイベントが発生しました。MarkReinholdは、半年ごとのJavaリリースのスケジュールへの切り替えを提案する書簡を発行し、これに続いてOracleからのメッセージが続きました。

• JDK 9 GAから、オラクルはGPLライセンスの下でOpenJDKビルドをリリースします
• Java SEは永続的なリリーススケジュールに切り替えます（マークの手紙）
• オラクルは、OpenJDKで以前の商用機能（Java Flight Recorderなど）を提供します
• オラクルは、他のOpenJDK開発者と提携して、最新の完全かつ手頃な環境を提供します。

Oracle JDKの商用バージョンは残っていますが、同社の目標は、OpenJDKと完全に互換性および互換性を持たせることです（2018年末まで）。

これは、プラットフォームとしてのJavaにとって非常に重要で必要なステップであるように思えます。 以下では、新しいリリーススケジュールがどのように機能するかを説明するマークの手紙の翻訳を提案します。

Javaの高速化

20年以上にわたり、Java SEプラットフォームとJDKは、大きく、不規則で、予測できないステップで前進してきました。 各機能リリースはいくつかの主要機能によって決定され、リリーススケジュールが変更されました-時には複数回！ -この機能の開発スケジュールに調整します。

このアプローチにより、慎重なレビューとテストの後、リリースに最高品質の新機能を含めることが可能になりました。 ただし、このアプローチの欠点は、API、言語、およびプラットフォームのより小さな機能は、 メイン機能の準備ができたときにのみ最終リリースに含めることができることです。

これは、Javaのライバルが同じ遅いペースで開発されていたわずかなプラットフォームであった世紀の変わり目の前後数十年の合理的な妥協でした。 しかし、最近では、Javaの競合他社がはるかに速く成長しています。

Javaの競争力を維持するためには、前進するだけでなく、速く進まなければなりません。

再び訓練する

5年前、私はこのブログ投稿で、速いイノベーションを好む開発者と安定性を好む企業との違いについて、そして本質的に誰もが定期的で予測可能なリリースを好むという事実について熟考しました。

両方の問題を解決するために、2年に1回リリースが予定どおりになったときに、リリースが機能セットによって決定される履歴リリースモデルから「トレーニング」モデルに切り替えることを提案しました。 このアプローチでは、開発がリリースに適応せず、イノベーションに関与しない場合があり、開発に関係なく、リリースには一定のスケジュールがあります。 （ほとんど）完全に準備が整った場合にのみ、大小の機能がリリースに含まれます。 機能の開発に現在のリリース「トレーニング」の時間がない場合-これは不快ですが、世界の終わりではありません。 次の「列車」は予定通り出発しました。

2年のスケジュールを持つ「電車」モデルは、理論上はかなり良いように見えましたが、実際には動作しないことが判明しました。 Java 8が重大なセキュリティ問題を解決し、Lambdaプロジェクトを完了するのにさらに8か月かかりました。これは、ラムダを2年間延期するよりも望ましい方法でした。 最初は、Java 9をProject Jigsawを含む2.5年のリリースとして計画し 、次の「電車」まで18か月間遅らせないようにしました。 しかし、最終的に、ファイナライズにもう1年かかりました。Java9は、Java 8の3.5年後の今月だけリリースされます。

振り返ってみると、2年のリリースサイクルは単純に遅すぎます。 定期的なスケジュールを達成するには、リリースをより頻繁にリリースする必要があります。 機能を次のリリースに移行することは、深刻な結果をもたらすグローバルなソリューションではなく、最小限の不都合を伴う戦術的なソリューションでなければなりません。

だから私の提案： 6ヶ月ごとにリリースしましょう 。

これは、次のリリースを待つ問題を回避するのに十分高速ですが、リリースが高品質を維持できるように十分に低速です。

申し出

他のプラットフォームおよびオペレーティングシステムのリリーススケジュールの例から着想を得て、Java 9のリリース後、6か月ごとの新機能リリース、四半期ごとの更新リリース、3年ごとのLTS（長期サポート）リリースを含む厳格な通常のリリーススケジュールに切り替えることを提案します。

• 機能リリースには、新規または更新されたAPIだけでなく、言語およびJVM機能を含む、あらゆる機能を含めることができます。 リリースでは新機能が導入され、最終段階で導入されるため、現在のリリースはいつでも機能が完了している必要があります。 機能リリースは、2018年3月から3月と9月に年2回リリースされます 。
• 更新リリースは、セキュリティ問題、リグレッションバグ、および新機能のバグの修正に厳密に制限されます。 各機能リリースには2つの更新リリースが含まれます。 更新リリースは、1月、4月、7月、10月に四半期ごとにリリースされます。
• 2017年9月から3年ごとに、機能リリースはLTSリリースになります。 LTSリリースのアップデートは、プロバイダーによっては少なくとも3年間、場合によってはそれより長く利用できます。

このモデルでは、全体的な変化率は現在と同じである必要があります。 ただし、重要な違いは、JDK開発者が新機能をリリースする機会がはるかに多くなることです。 半年ごとの機能リリースは、過去に多数の新機能を備えた複数年のリリースよりも少ないため、簡単に切り替えることができます。 半年ごとのリリースでも、コードを古いリリースに移植する難しさを軽減します（バックポート）。 それらの差は6か月を超えません。

革新と新機能を好む開発者は、新機能リリースまたは利用可能な最新のアップデートリリースを使用できます。 Dockerコンテナまたはその他の種類のコンテナにアプリケーションをパックして、必要なJavaの正確なバージョンを示すことができます。 このアプローチでは、 新しいJavaリリースとアプリケーションは、最新のCI / CDパイプラインを使用して互換性を簡単にテストでき、新しいリリースへの移行は簡単です。

単一の共有Javaリリースで複数の大きなアプリケーションを実行できるように安定性を好む企業開発者は、機能リリースの代わりにLTSを使用できます。 また、3年ごとに次のLTSの更新を予定どおりに計画することもできます。

厳密なスケジュールで新しいリリースをナビゲートし、特定のリリースがいつリリースされたかを簡単に理解できるように、リリースバージョンは$ YEAR。$ MONTHのようになります。 つまり、次の3月のリリースは18.3で、9月のLTSは18.9です。

結果

この提案が受け入れられた場合、 OpenJDKコミュニティの貢献者がJDKを直接生成する方法に大きな変更が必要になります。 このテーマに関する多くの考えを述べました。 このプロセスは、Java SEプラットフォームの開発を監督するJava Community Processによって生じるオーバーヘッドを削減できれば、はるかに簡単になります。 私の同僚ブライアンゲッツとジョージサブは、 JCP実行委員会との議論のためにこの問題をすでに提起しました。

このオファーは、最終的にJavaに依存するすべての開発者、ユーザー、および企業に影響を与えます。 また、正常に実装されれば、Javaの競争力を維持するのに役立ちますが、今後も長年にわたって下位互換性、信頼性、思慮深い開発などの一連の価値に依存しています。