Javaの時間ベースのリリース
1. 序章
この記事では、Javaの新しい時間ベースのリリースと、すべてのタイプの開発者への影響について説明します。
リリーススケジュールの変更には、Javaのバージョンの機能提供とサポートレベルの更新が含まれます。 全体として、これらの変更は、2010年以降OracleによってサポートされているJavaとは明らかに異なります。
2. なぜ6か月のリリースですか?
Javaの歴史的に遅いリリースのリズムに慣れている私たちにとって、これはかなり重要な出発点です。 なぜそのような劇的な変化?
もともと、Javaは、大きな機能の導入を中心にメジャーリリースを定義していました。 これは、Java8および9で経験したような遅延を引き起こす傾向がありました。 また、フィードバックサイクルがより緊密な他の言語が進化する一方で、言語の革新も遅くなりました。
簡単に言えば、リリース期間が短いほど、より小さく、より管理しやすいステップにつながります。 また、小さい機能は採用が容易です。
このようなパターンは現在の状況でうまくペアになり、JDK開発がサポートするコミュニティに似たアジャイル方法論で機能することを可能にします。 また、JavaをNodeJSやPythonなどのランタイムとの競争力を高めます。
もちろん、ペースが遅いことにもメリットがあるため、6か月のリリースサイクルは、セクション4で説明するより大きなロングタームサポートフレームワークでも役割を果たします。
3. バージョン番号の変更
この変更の機械的な側面は、新しいバージョン番号スキームです。
3.1. JEP223バージョン-文字列スキーム
私たちは皆、 JEP223で成文化された古いものに精通しています。 このスキームにより、バージョン番号が増分され、追加情報が中継されました。
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の倍数であり、セキュリティリリースは他のすべてを満たしていました。 通常、JDK1.8u174などの短い文字列がローカルインストールに追加されます。次のリリースはJDK 1.8u180で、新しい修正が加えられたマイナーリリースになります。 。
3.2. 新しいバージョン-文字列スキーム
新しいバージョン文字列スキームは、「バージョン番号を再キャストして、互換性と重要性ではなく、リリースサイクルの観点から時間の経過をエンコードします」
いくつか見てみましょう:
9.0.4
11.0.2
10.0.1
一見すると、これはセマンティックバージョニング ;
セマンティックバージョニングでは、一般的な構造は$MAJOR。$MINOR。$PATCHですが、Javaの新しいバージョン構造は次のとおりです。
$FEATURE.$INTERIM.$UPDATE.$PATCH
$ FEATUREは、メジャーバージョンと考えることができますが、互換性の保証に関係なく、6か月ごとに増分します。 また、 $PATCHはメンテナンスリリース用です。 しかし、これは類似点が止まるところです。
まず、 $ INTERIM はプレースホルダーであり、将来のニーズに備えてOracleによって予約されています。 当面は常にゼロになります。
次に、 $UPDATEは$FEATUREのように時間ベースであり、最新の機能リリース後に毎月更新されます。
そして最後に、末尾のゼロは切り捨てられます。
つまり、 11は2018年9月にリリースされたJava11のリリース番号、 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のバグ修正を適用するためのサポートを表明しています。 また、 AdaptOpenJDK プロジェクトは、OpenJDK用のビルド済みバイナリを提供します。
4.3. ライセンス
一部の人にとって混乱する領域の1つは、OpenJDKとOracleJDKの違いです。
実際、これらはほぼ同じであり、Brian Goetz によると、バグ修正とセキュリティパッチが適用されている点のみが異なります。
OpenJDKは、ほとんどの派生JDKのソースとして機能し、無料のままです。 Java 11以降、Oracleは、追加のサポートとサービスを含めて、OracleJDKの商用ライセンス料金を請求します。
4.4. 断片化
より頻繁なリリースでは、断片化が問題になる可能性があります。 仮に、誰もが今よりもさらに多くの異なる機能を備えた異なるバージョンのJavaで実行されている可能性があります。
もちろん、コンテナ化はこれに対処するのに役立ちます。 DockerやCoreOSからRedHatのOpenShiftまで、コンテナー化により必要な分離が提供され、サーバー全体でJavaの1つのインストール場所が強制的に使用されることはなくなりました。
5. 結論
結論として、6か月ごとにJavaが定期的にリリースされることで、OracleのJavaチームにはさらに多くのことが期待できます。 Java開発者として、6か月ごとの新しい言語機能の見通しはエキサイティングです。
サポートとライセンスが必要な場合のアップグレードチャネルと、断片化への対処方法を決定する際には、いくつかの影響を念頭に置いてください。