After two years in the current format, the Java version scheme is going to be modified from Java 9 onwards. The change will follow best practices in software versioning across the industry. Application developers that use or parse the Java version string should be vigilant, since the change may impact their applications.
As explained in JEP 223, the current version scheme, which skips certain version numbers and mixes security fixes with updates, is perceived as cryptic and counter-intuitive by the community. In order to fix this, Oracle is introducing a new version scheme that uses semantic versioning, meaning the Java version string will be composed of three numbers: a major release number, followed by a minor (or maintenance) release number, followed by a security release number. A long version format will also include information like build number and availability.
The major release number will match what is commonly understood as the version of Java, i.e. the major release number of Java 9 will be 9. Therefore, a change in the major release number will only happen once every two or three years, according to the release of new versions of Java. Changes in the major release number may include breaking changes, but these will be notified at least two major versions in advance.
The minor release number will include non-critical bug fixes, maintenance releases for supported APIs, and the addition of internal components like new service providers, new garbage collectors, or support for new architectures. Minor releases are expected to happen quarterly, like Patch Set Updates.
Finally, security releases will include critical bug fixes. These may happen either in a quarterly schedule, like Critical Patch Updates, or on demand, like Security Alerts.
One notable conclusion of this is that Oracle will drop the leading "1." in the version number, recognising the fact that the community understands the current second digit as the de facto major release number, while the leading 1 is understood to have no meaning. This change may cause trouble on applications that currently parse the version string expecting a leading 1 or a dot; for instance, and as noted in the JEP, the following code:
System.getProperty("java.version").indexof('.');
will return -1 for major releases (trailing zeroes will be removed from the version string, so 9.0.0 will simply be expressed as 9).
This becomes the third standard for the Java version string. The first one, in place since Java 1.3, was rather simple, using the second digit as the effective major release and the third digit to indicate either a security fix (odd numbers) or an upgrade (even numbers). This system had its limitations, and forced releases to be renumbered at times.
To fix this, the current versioning system was introduced. Under the current scheme security fixes still use odd numbers and updates use even numbers, although not consecutive ones. Updates are always multiples of 20, while the version of CPUs is calculated by adding multiples of 5 to the latest maintenance update (adding 1 if necessary to keep the number odd). This way, if a maintenance release number is 20, the following scheduled security releases will be 25, 31 and 35. The gaps between release numbers allow for security alert fixes to be released without having to renumber other scheduled releases.
The new versioning system aims at keeping a way to distinguish between updates and security fixes, although in a way that is much more easy to recognise.
