現在の形式になって２年，JavaのバージョンスキーマがJava 9から変更されることになった。今回の変更は，業界全体のソフトウェアバージョニングのベストプラクティスに従うものだ。Javaのバージョン文字列を使用，あるいは解析しているアプリケーションの開発者は，この変更による影響に注意する必要がある。
JEP 223で説明されているように現行のバージョンスキーマは，特定のバージョン番号がスキップされていたり，セキュリティフィックスとアップデートが混在しているため，コミュニティには直感的でなく分かりにくいと思われている。この問題を解決するためにOracleは，セマンティックバージョニングを用いた新たなバージョンスキーマの導入を予定している。この形式では，Javaのバージョン文字列を３つの数字によって構成する - メジャーリリース番号とそれに続くマイナー(あるいはメンテナンス)番号，そしてセキュリティリリース番号である。長形式のバージョンフォーマットには，ビルド番号やアベイラビリティなどの情報も含まれる。
メジャーリリース番号は，コミュニティがJavaのバージョンとして認識しているバージョン番号と一致する。例えば，Java 9のメジャーリリース番号は9である。従ってメジャーリリース番号の変更が行われるのは，Javaの新バージョンのリリースと同じで，２年ないし３年に１回のみになる。メジャーリリース番号の更新時には互換性のない変更が含まれる可能性があるが，これらは事前に，少なくとも２メジャーバージョン前には通知される予定である。
マイナーリリース番号には，緊急性のないバグフィックスやサポートAPIのメンテナンスリリース，あるいは新しいサービスプロバイダなど新規コンポーネントの追加，新しいガベージコレクタ，新たなアーキテクチャのサポートといったものが含まれる。マイナーリリースはパッチセットアップデートと同じように，四半期毎の実施を予定している。
最後のセキュリティリリースは，重要なバグフィックスを行うためのものだ。このリリースは，クリティカルパッチアップデート(CPU)と同じ四半期毎のスケジュールに加えて，セキュリティアラートのようなオンデマンドでも実施される予定である。
決定事項で注目すべきなのは，Oracleがバージョン番号の最初の“1.”を廃止する予定だということだ。この１が意味を持たないことは理解できるが，コミュニティの中では，現行の２番目の数字はデファクトメジャーリリース番号と解釈されている。この変更は，現行のバージョン番号の解析処理において，先頭に１またはドットがあることを前提とするアプリケーションに影響を与える可能性がある。例えば，JEPにもあるように，次のようなコードは，
System.getProperty("java.version").indexof('.');
メジャーリリースには-1を返すことになる(後続０はバージョン文字列から省かれることから，9.0.0は単純に9と表現されるため)。
今回の標準は，Javaバージョン文字列として３番目にあたる。1.3以降に採用された最初のものは比較的シンプルで，２番目の数字を実質的なメジャーリリース，３番目をセキュリティフィックス(偶数)またはアップグレード(奇数)として使用していた。このシステムには制限があるため，リリース番号の再定義を余儀なくされることが何度かあった。
この問題を解決するために，現在のバージョニングシステムが導入された。現在のスキーマでもセキュリティフィックスは偶数でアップデートは奇数だが，連続した数字ではない。アップデートは常に20の倍数で，最新のメンテナンスアップデートに５の倍数を加えてCPU(Critical Patch Update)のバージョンが決められる(奇数にするために，必要に応じて１が加えられる)。この方法に従えば，例えばメンテナンスリリース番号が20の場合，それ以降にスケジュールされるセキュリティリリースは25, 31, 35になるはずだ。リリース番号の間のギャップは，すでにスケジュールされているリリース番号を変更しなくても，セキュリティ警告の修正をリリース可能にするために設けられている。
新しいバージョニングシステムは，アップデートとセキュリティフィックスを区別する方法を維持しながら，より理解しやすい方法であることを目標とする。