Javaの時間ベースのリリース

  • link:/category/architecture/ [アーキテクチャ]

  • Java

1. 前書き

この記事では、Javaの時間ベースの新しいリリースと、あらゆるタイプの開発者への影響について説明します。
リリーススケジュールの変更には、Javaのバージョンの機能提供とサポートレベルの更新が含まれます。 全体的に、これらの変更は2010年以降にOracleでサポートされているJavaとは明らかに異なります。

2. 6か月リリースする理由

Javaの歴史的に遅いリリースリズムに慣れている私たちにとって、これはかなり重要な出発点です。 なぜそんなに劇的な変化があったのですか?
当初、Javaは大規模な機能の導入に関するメジャーリリースを定義していました。 これには、私たち全員がJava 8および9で経験したような遅延が生じる傾向がありました。 また、言語の革新を遅らせた一方で、フィードバックサイクルがよりタイトな他の言語が進化しました。
*簡単に言えば、リリース期間を短くすると、より小さく、管理しやすい手順になります。 また、より小さい機能を採用するのが簡単です。*
このようなパターンは現在の状況ではうまくペアになり、JDK開発がサポートするコミュニティに似たアジャイルな方法論で動作することを可能にします。 また、NodeJSやPythonなどのランタイムとJavaの競争力を高めます。
もちろん、ペースが遅いことにもメリットがあるため、6か月のリリースサイクルは、セクション4で説明する長期サポートフレームワークでも重要な役割を果たします。

3. バージョン番号の変更

この変更の機械的な側面は、新しいバージョン番号スキームです。

3.1. JEP 223バージョン文字列スキーム

私たちは皆、古いものに精通しており、https://openjdk.java.net/jeps/223[JEP 223]で体系化されています。 このスキームにより、バージョン番号が増分され、追加情報が中継されました。
   Actual                    Hypothetical
Release Type           long               short
------------           ------------------------
Security 2013/06       1.7.0_25-b15       7u25
Minor    2013/09       1.7.0_40-b43       7u40
Security 2013/10       1.7.0_45-b18       7u45
Security 2014/01       1.7.0_51-b13       7u51
Minor    2014/05       1.7.0_60-b19       7u60
*バージョン8以前のJVMで_java -version_を実行すると、次のように表示されます。*
>java -version
java version "1.6.0_27"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0_27-b07)
Java HotSpot(TM) Client VM (build 1.6.0_27-b13, mixed mode, sharing)
この場合、これが正しいのはJava 6であり、27回目の更新は間違っていると推測される場合があります。 番号付けスキームは、見た目ほど直感的ではありません。
マイナーリリースは10の倍数であり、セキュリティリリースは他のすべてを満たしていました。 通常、ローカルインストールに_JDK.1.8u174._などの短い文字列が追加されます。次のリリースは_JDK_ 1.8u180であり、これは新しい修正を含むマイナーリリースになります。

3.2. 新しいバージョン文字列スキーム

新しいバージョン文字列スキームは「互換性や重要性ではなく、リリースサイクルの観点から時間の経過をエンコードするためにバージョン番号を再キャストします_」https://openjdk.java.net/jeps/322 [ JEPでマーク・ラインホールド]。
いくつか見てみましょう:
9.0.4
11.0.2
10.0.1
一見すると、これはセマンティックバージョニングのように見えます。 *ただし、そうではありません。 *
セマンティックバージョニングでは、典型的な構造は_ $ MAJOR。$ MINOR。$ PATCH_ですが、Javaの新しいバージョン構造は次のとおりです。
$FEATURE.$INTERIM.$UPDATE.$PATCH
  • _ $ FEATURE_はメジャーバージョンと考えられるものですが、互換性の保証に関係なく6か月ごとに増分されます。 _ $ PATCH_はメンテナンスリリース用です。 しかし、これは類似点が止まるところです。

    まず、_ $ INTERIM_はプレースホルダーであり、将来のニーズのためにOracleによって予約されています。 *当面は、常にゼロになります。*
    2番目に、* _ $ UPDATE_は、time __ $ FEATUREのように時間ベースであり、__最新の機能リリース後に毎月更新されます*。
    そして最後に、末尾のゼロは切り捨てられます。
    これは、_11_が2018年9月にリリースされたJava 11のリリース番号であり、__11.0.1 __が10月の最初の月次アップデートリリースであり、_11.0.1.3_が10月のバージョンからの仮想の3番目のパッチリリースであることを意味します。

4. 複数のバージョンの配布

次に、適切なバージョンを選択する方法を見てみましょう。

4.1. 安定

*簡単に言えば、Javaには6か月ごとに高速チャンネルがあり、3年ごとに低速チャンネルがあります。* * 3年目の各リリースはLTSリリースと呼ばれます。*
高速チャネルでは、言語はインキュベーションで機能をリリースします。 これらの言語機能は、LTSリリースで安定します。
そのため、新機能の使用と引き換えにボラティリティを取り入れることができる企業にとっては、高速チャネルを使用できます。 安定性を評価し、アップグレードを待つことができる企業の場合、LTSのリリースごとにアップグレードできます。
JDKバージョンの実験により、開発者は最適なものを見つけることができます。

4.2. サポート

もちろん、サポートの問題もあります。 Java 8のサポートが終了したので、どうしますか?
前述のように、答えはLTSバージョンにあります。* Java 11が最新のLTSリリースで、17が次のリリースです*。 更新プログラムは、OracleやAzulなどのベンダーによって利用可能およびサポートされます。
コミュニティのサポートを信頼できる場合、Redhat、IBM、および他の人々は、OpenJDKのバグ修正を適用するためのサポートを表明しています。 また、https://adoptopenjdk.net/ [AdoptOpenJDK]プロジェクトは、OpenJDKのビルド済みバイナリを提供します。

4.3. 免許

一部の人にとって混乱の1つの領域は、OpenJDKとOracle JDKの違いです。
実際、これらはほぼ同じであり、バグ修正とセキュリティパッチが取り上げられている点だけが異なります。https://www.infoq.com/podcasts/java-language-architect-brian-goetz [Brian Goetzによる]。
  • OpenJDKは、ほとんどの派生JDKのソースとして機能し、無料のままです。* Java 11以降、オラクルは、追加のサポートとサービスを含むOracle JDKの商用ライセンス料金を請求します。

4.4. フラグメンテーション

より頻繁なリリースでは、断片化が問題になる可能性があります。 仮に、誰もが今よりもさらに異なる機能を備えた異なるバージョンのJavaで実行できます。
もちろん、コンテナ化はこれに対処するのに役立ちます。 DockerやCoreOSからRed HatのOpenShiftまで、コンテナー化は必要な分離を提供し、サーバー全体でJavaの1つのインストール場所を使用することを強制しなくなりました。

5. 結論

結論として、6か月ごとにJavaを定期的にリリースすることで、OracleのJavaチームからさらに多くのことが期待できます。 Java開発者として、6か月ごとの新しい言語機能の可能性は刺激的です。
サポートとライセンスが必要な場合のアップグレードチャネルと、断片化への対処方法を決定する際に、いくつかの影響を念頭に置いてください。