Java 9は新しいバージョン文字列フォーマットを採用します

既存のバージョンエンコーディングフォーマットが2年使用された後、Java 9から、Javaバージョンスキームは業界内のソフトウェアバージョンエンコーディングのベストプラクティスに基づいて修正されます.Javaバージョンの文字列を使用または解析するアプリケーション開発者は、この変化がアプリケーションに影響を与える可能性があるため、注意してください.
JEP 223で説明したように、現在のバージョンスキームでは、バージョン番号がスキップされ、セキュリティパッチバージョンと更新バージョンが混在します.コミュニティは、このスキームが生成したバージョン番号の意味が曖昧で、直感的ではないと考えています.この問題を解決するために、Oracleでは、Javaバージョン文字列には、プライマリ・バージョン番号、ミニ(メンテナンス)バージョン番号、セキュリティ・バージョン番号の3つの部分が順次含まれるという意味バージョン符号化を使用した新しいバージョン・スキームが導入されました.ロングバージョンフォーマットには、構築バージョン番号や可用性などの情報も含まれます.
プライマリ・バージョン番号は、Java 9のプライマリ・バージョンが9であるなど、一般的に理解されているJavaバージョンです.そのため、Javaの新しいバージョンのリリース計画によると、メインバージョンの変更は2年か3年に1回しか発生しません.プライマリ・バージョンの変更には破壊的な変更が含まれる場合がありますが、これらの変更は少なくとも2つのプライマリ・バージョンで通知されます.
イテレーション番号には、重要でないバグ修正、サポートされているAPIのメンテナンスリリース、および新しいサービスプロバイダ、新しいゴミ収集器、または新しいアーキテクチャをサポートするなどの内部コンポーネントが追加されます.パッチセットの更新と同様に、イテレーションは四半期ごとにリリースされる見込みです.
最後に、セキュリティバージョンには重要なバグ修正が含まれます.これらのバージョンは、重要なパッチ更新のように計画に基づいて四半期ごとにリリースされるか、セキュリティ・アラートのようにオンデマンドでリリースされる可能性があります.
この点について、コミュニティが現在のバージョン番号の2番目の数字を事実上のプライマリ・バージョン番号として認識し、先頭の1が意味がないと理解された後、Oracleはバージョン番号の先頭の「1」を削除したことに注目してください.この変更により、現在バージョン文字列が解析され、バージョン番号の先頭が1またはポイントであると仮定したアプリケーションに問題が発生する可能性があります.たとえば、

System.getProperty("java.version").indexof('.');

上記のマスターバージョンを取得したコードは-1を返します(末尾の0はバージョン文字列から削除されるため、9.0.0は簡単に9として表されます).
新しいシナリオはJavaバージョン文字列の3番目の基準になります.最初はJava 1.3から始まります.このスキームはかなり簡単で、2番目の数字を実際のプライマリ・バージョンとして使用し、3番目の数字はセキュリティ修復(奇数)か更新(偶数)かを示します.この符号化システムには欠陥があり、一部のバージョンを再符号化させることがある.
この問題を解決するために、Oracleは現在のバージョンシステムを導入しました.現在のシナリオでは、セキュリティパッチは奇数を使用し、更新は偶数を使用します.連続していませんが.更新は常に20の倍数で、重要パッチ更新のバージョンは最新のメンテナンス更新に5の倍数(バージョン番号が奇数であることを保証するために必要な場合は1を加算)を加えることで算出されます.これにより、メンテナンス・バージョン番号が20の場合、計画に従って、後続のセキュリティ・バージョンは25、31、35になります.バージョン番号の間に残された数字は、セキュリティ・アラート・パッチのパブリケーションに使用されます.これにより、他の計画されたバージョン番号を再エンコードする必要がなくなります.
新しいバージョン符号化システムは、更新とセキュリティパッチを区別できる方法を採用することを目的としており、識別が簡単で多くの方法である.
Java Version Strings Evolve for Java 9