Javaの新バージョンはJDK 1.9ではありません。
2560 ワード
JDK強化提案（JEP）223は、主要バージョン、小バージョン、およびセキュリティバージョンの識別をより簡単にするための新しいJDKバージョンの命名規則である。それはより簡単で、より直感的で、解析しやすく、現在の業界のやり方と一致しています。特に「セマンティック・バージョン名」のルールです。例えば、新しいバージョンの命名規則を使用すると、バージョン文字列JDK 1.7.0_65-b 20（7 u 65）はJDK 7.6.15+20（7.6.15）になります。
既存のJDKバージョンの命名規則では、「JDK 7 Update 65」、「JDK 1.7.0_65」と「JDK 7 u 65」は同じバージョンの異なる名前です。これらのバージョンを識別して比較するには、解析されたマーク毎の点の比較だけでは不十分であり、かなり複雑なアルゴリズムが必要である。また、小文字の「u」は業界標準でもなければ、言語に関係ないものでもありません。既存のJDK数字命名規則では、小バージョンは20の倍数であり、安全修復以外の更新を含む。セキュリティバージョンは奇数で、前の小バージョンに5または6を加えて導出します。このような数字の命名ルールに慣れていないユーザーは、「JDK 7 Update 60」は「JDK 7 Update 55」以降の5番目のバージョンであり、前者がより安全な修復があると誤って認識することがあります。小さいバージョンとセキュリティバージョンのこのような一つの数値で符号化する方法は分かりにくく、多くのバージョンもスキップします。
JEP 223の目標：バージョンは分かりやすく解析するべきで、現在の意味バージョンとこの業界のやり方は一致しているはずであり、既存のパッケージと配置システムによって使用されるべきである。提案はまた、バージョンの文字列解析、検証、比較のためのAPIを提供する。以前のJDKバージョンのバージョン文字列フォーマットを変更することは提案の目的ではありません。
バージョン番号は、非負の整数からなる非空のシーケンスで、ピリオドで区切られます。プリアンブルゼロは含まれていません。正規表現［1-9]、[0-9]*(\.（0|［1-9]、[0-9]*)にマッチします。前の三つの基本部分は$MAJOR.$MINOR.$SECURITYです。メインバージョンには、新Java SEプラットフォーム仕様で指定された重要な新特性が含まれており、そのリリース時には$MAJORが増加します。小さい更新バージョンは、互換性のあるBug修復、標準APIの修正、新しいゴミ収集器の実現、または新しいハードウェアアーキテクチャのサポートなどの新しい特性を含むことができ、そのリリース時には$MINORが増加します。セキュリティアップデートバージョンには重要なパッチが含まれており、リリース時にはSECURITYが増加します。$MAJORが増加すると、$MINORと$SECURITYは0にリセットされます。MAJORの値が一定の場合、$MINORの値がいくらであっても、$SECURITYの値が大きいほど、より安全なバージョンであることが示されます。
バージョン文字列はバージョン番号、オプションのプリリリースおよび構築情報から構成されています。プリリリースされたロゴは、初期の試用バージョンを表しており、アクティブな開発状態にあります。構築が完了するたびに、内部バージョン番号が増加します。バージョン番号の一部が追加されると、内部バージョン番号はいずれも1にリセットされます。文末ゼロを削除したバージョン文字列をショートバージョン文字列と呼びます。以下の表では、JDK 9の可能なバージョン文字列の2つを比較し、既存のフォーマットと提案フォーマットを含む。既存のJDKバージョン番号は常に1で始まるコードでは正常に動作しないと仮定しています。
New Java Version-it's not JDK 1.9
既存のJDKバージョンの命名規則では、「JDK 7 Update 65」、「JDK 1.7.0_65」と「JDK 7 u 65」は同じバージョンの異なる名前です。これらのバージョンを識別して比較するには、解析されたマーク毎の点の比較だけでは不十分であり、かなり複雑なアルゴリズムが必要である。また、小文字の「u」は業界標準でもなければ、言語に関係ないものでもありません。既存のJDK数字命名規則では、小バージョンは20の倍数であり、安全修復以外の更新を含む。セキュリティバージョンは奇数で、前の小バージョンに5または6を加えて導出します。このような数字の命名ルールに慣れていないユーザーは、「JDK 7 Update 60」は「JDK 7 Update 55」以降の5番目のバージョンであり、前者がより安全な修復があると誤って認識することがあります。小さいバージョンとセキュリティバージョンのこのような一つの数値で符号化する方法は分かりにくく、多くのバージョンもスキップします。
JEP 223の目標：バージョンは分かりやすく解析するべきで、現在の意味バージョンとこの業界のやり方は一致しているはずであり、既存のパッケージと配置システムによって使用されるべきである。提案はまた、バージョンの文字列解析、検証、比較のためのAPIを提供する。以前のJDKバージョンのバージョン文字列フォーマットを変更することは提案の目的ではありません。
バージョン番号は、非負の整数からなる非空のシーケンスで、ピリオドで区切られます。プリアンブルゼロは含まれていません。正規表現［1-9]、[0-9]*(\.（0|［1-9]、[0-9]*)にマッチします。前の三つの基本部分は$MAJOR.$MINOR.$SECURITYです。メインバージョンには、新Java SEプラットフォーム仕様で指定された重要な新特性が含まれており、そのリリース時には$MAJORが増加します。小さい更新バージョンは、互換性のあるBug修復、標準APIの修正、新しいゴミ収集器の実現、または新しいハードウェアアーキテクチャのサポートなどの新しい特性を含むことができ、そのリリース時には$MINORが増加します。セキュリティアップデートバージョンには重要なパッチが含まれており、リリース時にはSECURITYが増加します。$MAJORが増加すると、$MINORと$SECURITYは0にリセットされます。MAJORの値が一定の場合、$MINORの値がいくらであっても、$SECURITYの値が大きいほど、より安全なバージョンであることが示されます。
バージョン文字列はバージョン番号、オプションのプリリリースおよび構築情報から構成されています。プリリリースされたロゴは、初期の試用バージョンを表しており、アクティブな開発状態にあります。構築が完了するたびに、内部バージョン番号が増加します。バージョン番号の一部が追加されると、内部バージョン番号はいずれも1にリセットされます。文末ゼロを削除したバージョン文字列をショートバージョン文字列と呼びます。以下の表では、JDK 9の可能なバージョン文字列の2つを比較し、既存のフォーマットと提案フォーマットを含む。既存のJDKバージョン番号は常に1で始まるコードでは正常に動作しないと仮定しています。
Existing Proposed
Release Type long short long short
------------ -------------------- --------------------
Early Access 1.9.0-ea-b19 9-ea 9.0.0-ea+19 9-ea
Major 1.9.0-b100 9 9.0.0+100 9
Security #1 1.9.0_5-b20 9u5 9.0.1+20 9.0.1
Security #2 1.9.0_11-b12 9u11 9.0.2+12 9.0.2
Minor #1 1.9.0_20-b62 9u20 9.1.2+62 9.1.2
Security #3 1.9.0_25-b15 9u25 9.1.3+15 9.1.3
Security #4 1.9.0_31-b08 9u31 9.1.4+8 9.1.4
Minor #2 1.9.0_40-b45 9u40 9.2.4+45 9.2.4
New Java Version-it's not JDK 1.9