According to this blog on Java 9\'s new version string scheme, the version is supposed to be like MAJOR.MINOR.SECURITY
, i.e., there are supposed to be 3 numbers and
That blog posting is a bit out of date. The actually implemented scheme in Java 9 is documented in JEP 223: New Version-String Scheme
The meaning of the first three numbers is standardized. The meaning of the 4th and (any) subsequent numbers are left to the vendor to specify.
Note also the interesting relationship between the 2nd and 3rd numbers.
Here are the relevant parts of the JEP.
"The sequence may be of arbitrary length but the first three elements are assigned specific meanings, as follows:
$MAJOR.$MINOR.$SECURITY
$MAJOR
- The major version number, incremented for a major release that contains significant new features as specified in a new edition of the Java SE Platform Specification, e.g., JSR 337 for Java SE 8. Features may be removed in a major release, given advance notice at least one major release ahead of time, and incompatible changes may be made when justified. The$MAJOR
version number of JDK 8 is 8; the$MAJOR
version number of JDK 9 is 9. When$MAJOR
is incremented, all subsequent elements are removed.
$MINOR
- The minor version number, incremented for a minor update release that may contain compatible bug fixes, revisions to standard APIs mandated by a Maintenance Release of the relevant Platform Specification, and implementation features outside the scope of that Specification such as new JDK-specific APIs, additional service providers, new garbage collectors, and ports to new hardware architectures.
$SECURITY
- The security level, incremented for a security-update release that contains critical fixes including those necessary to improve security.$SECURITY
is not reset to zero when$MINOR
is incremented. A higher value of$SECURITY
for a given$MAJOR
value, therefore, always indicates a more secure release, regardless of the value of$MINOR
.The fourth and later elements of a version number are free for use by downstream consumers of the JDK code base. Such a consumer may, e.g., use the fourth element to identify patch releases which contain a small number of critical non-security fixes in addition to the security fixes in the corresponding security release.
i.e., there are supposed to be 3 numbers and 2 periods in between.
Not necessarily and you can validate the versions using the JDK itself as detailed below.
In addition to the JEP which holds true as linked by @Stephen in the other answer, there has been an API addition to the JDK as well for the Runtime.Version which can be used to validate a given version string. This can be done using a sample stub as :
[I wonder using JShell could be interesting here, no IDEs!]
Runtime.Version version = Runtime.Version.parse("9");
version = Runtime.Version.parse("9.0.1");
version = Runtime.Version.parse("9.0.0.15");
version = Runtime.Version.parse("9.0.0.15+181");
The code makes use of the Version.parse that
Parses the given string as a valid version string containing a version number followed by pre-release and build information.
and can be further used(primarily) to get information like major, minor, pre-release and security number of the (runtime) version.