New Java Version - it's not JDK 1.9
JDK Enhancement Proposal (JEP) 223 is a new JDK versioning scheme to make it easier to distinguish major, minor, and security releases. It's simpler, more intuitive, easier to parse, and aligns with current industry practices, in particular Semantic Versioning. For example, if JDK 1.7.0_65-b20 (7u65) used this new versioning scheme, the version string would be JDK 7.6.15+20 (7.6.15).
In the existing JDK versioning scheme, "JDK 7 Update 65", "JDK 1.7.0_65", and "JDK 7u65" are different names for the same release. To identify and compare releases, a simple pointwise comparison of parsed tokens is not enough, and a fairly sophisticated algorithm is required. The use of the lower-case 'u' is also not an industry standard and is not language-neutral. In the current JDK numbering scheme, minor releases containing changes beyond security fixes are multiples of 20. Security releases based on the previous minor release are odd numbers incremented by five or six. Those not versed in this numbering scheme would think that "JDK 7 Update 60" is 5 releases later than "JDK 7 Update 55" and incorrectly assume the former has more security fixes. This practice of encoding the minor and security versions in one number is not easy to decipher and also results in skipping many versions.
The goals of JEP 223 are: the version should be easy to understand and easy to parse, it should align with current industry practices of Semantic Versioning, and it should be adoptable by existing packaging and deployment systems. The JEP will also provide an API for version string parsing, validation, and comparison. It is not the goal of this JEP to change the version string format used by a previous JDK release.
A version number is a non-empty sequence of non-negative integer numerals, separated by period characters. It does not contain leading zeroes, and matches the regular expression [1-9][0-9]*(\.(0|[1-9][0-9]*))*. The first three elements are $MAJOR.$MINOR.$SECURITY. $MAJOR is incremented for a major release that contains significant new features as specified in a new Java SE Platform Specification. $MINOR is incremented for a minor update release that may contain compatible bug fixes, revisions to standard APIs and implementation features like new garbage collectors or support for new hardware architectures. $SECURITY is incremented for a security-update release that contains critical fixes. $MINOR and $SECURITY is reset to zero when $MAJOR is incremented. A higher $SECURITY value for a given $MAJOR value indicates a more secure release, regardless of the $MINOR value.
A version string consists of a version number, optionally followed by pre-release and build information. The pre-release identifier ea is for an early-access release that's under active development. The build number is incremented for each promoted build, and reset to 1 when any portion of the version number is incremented. The version string with trailing zero elements omitted is called the short version string. The following compares the potential version strings for JDK 9 using the current and proposed formats. Note that existing code that assumes the JDK version always starts with a 1 will no longer work correctly.
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
The JEP was created on October 20, 2014 and is under Candidate status for release with JDK 9. For more information, including a sample JDK Java API, please read JEP 223 and JBS (JDK Bug System) 8061493.
Can't imagine Java 9.2.4!
Definitely meaningful goal though.
Re: Can't imagine Java 9.2.4!
Re: Can't imagine Java 9.2.4!