Java 9 will be formatted with the new version string

After two years of using the existing version encoding format, starting with Java 9, the Java version scenario will be modified based on best practices for the industry software version coding. Application developers who use or parse Java version strings should be aware that this change can affect their applications.
As Jep 223 illustrates, the current version scenario skips some version numbers, and the security patch version and the updated version are mixed together. The community believes that the version number produced by the scheme is ambiguous and not intuitive. To solve this problem, Oracle introduces a new version of the schema that encodes the semantic version, meaning that the Java version string will contain the following three parts: Major, minor (maintenance), and security. The long version format will also contain information like build version number and availability.
The major version number is the Java version that we usually understand, for example, the main version of Java 9 is 9. Therefore, according to the new version of Java release plan, the major version of the changes will only occur two or three years. Changes to the major version may contain disruptive changes, but these changes will be notified at least two major releases in advance.
The minor version number will contain non-critical bug fixes, maintenance releases of supported APIs, and additional internal components such as new service providers, new garbage collectors, or support for new schemas. As with update patch sets, the iteration is expected to be released quarterly.
Finally, the security version will contain important bug fixes. These versions may be released on a quarterly basis, as is the case with important patch updates, or as on-demand as security alerts.
One notable conclusion about this is that, recognizing that the community has the second number in the current version number as the de facto major version number, and that the beginning of 1 is understood to be meaningless, Oracle removes "1" from the beginning of the version number. This change may cause problems with applications that currently parse the version string and have the assumption that the version number starts at 1 or point. For example
System.getproperty ("Java.version"). indexof ('. ');
The code that gets the main version above returns 1 (the trailing 0 is removed from the version string, so the 9.0.0 is simply represented as 9).
The new scenario will be the third standard for Java version strings. The first one starts with Java 1.3. The scheme is quite simple, using the second number as the actual major version, and the third number indicates whether it is a security fix (odd) or an update (even). This coding system is flawed and sometimes forces some versions to Recode.
To solve this problem, Oracle introduced the current version of the system. In the current scenario, the security patches still use odd numbers, and the updates still use even numbers, albeit not consecutively. Updates are always multiples of 20, and critical patch updates are calculated by adding a multiple of 5 to the latest maintenance update (to ensure that the version number is odd, plus 1 if necessary). Thus, if the maintenance version number is 20, then according to the plan, subsequent security versions will be 25, 31, and 35. The numbers left between the version numbers will be used for security alert patches, so there is no need to recode other planned version numbers.
The new version coding system is designed to take a way to differentiate between updates and security patches, and is a much simpler way to identify.

Java 9 will be formatted with the new version string