It’s a done deal! The next Java version will be JDK 10

It’s done! After never-ending discussions and countless options, we know now that the next Java version will be JDK 10.

Mark Reinhold announced the decision [since there were no objections] in a message to the OpenJDK mailing list.

It’s official! The next release of #Java will be JDK 10 #JDK10. https://t.co/uYB51Ni41J

— Simon Ritter (@speakjava) 14. Dezember 2017

Update December 5, 2017

The road to JDK 10: What we know so far

It ain’t over until the fat lady sings. The story goes like this: three months ago, Mark Reinhold, the Chief Architect of the Java Platform Group at Oracle, proposed that the Java SE Platform and the JDK go from “the historical feature-driven release model to a strict, time-based model with a new feature release every six months, update releases every quarter, and a long-term support release every three years.”

Suffice it to say that people didn’t like the idea — Stephen Colebourne even wrote a plea “for sane Java version numbers such as 10, 11, 12”. However, as Falk Sippach pointed out in a recent interview, “no one knows whether it really is going to go this way.”

From JEP 223 to JEP 322

Turns out Falk was right all along: Oracle offered three alternatives and presented a specific proposal in early November. Mark Reinhold’s proposal was “even closer to the current scheme as defined in JEP 223 and less likely to surprise, and should be easier to adopt.”

After reasonable objections were raised against this scheme [March 2018 release would be 18.3, the September release would be 18.9 etc] we reviewed the various types of information encoded in version numbers and suggested some alternatives, then summarized and responded to the discussion that followed, and finally published a proposal that was well received and hence became the basis for this JEP.

Mark Reinhold

It’s time to say goodbye to the scheme introduced by JEP 223 since it’s no longer “well-suited to the [six-month cadence] future”.  Therefore, the main change is “to recast version numbers to encode not compatibility and significance but, rather, the passage of time, in terms of release cycles.”

According to Mark Reinhold, “this is a better fit for time-based release models since each release cycle, and thus each release’s version number is always known well in advance.”

SEE ALSO: Back to JDK 10: “Most feature releases should contain at least one or two significant features”

$FEATURE.$INTERIM.$UPDATE.$PATCH, where $FEATURE starts at 10 and is incremented every six months #jdk10 #jdk #openjdk #java https://t.co/ZpryUXT7rn

— Mark Reinhold (@mreinhold) December 4, 2017

JEP 322 goals:

• Recast the version-number scheme introduced by JEP 223 so that it better fits time-based release models that define feature releases, which can contain new features, and update releases, which only fix bugs.
• Allow for time-based release models other than the current model, with a different cadence or with interim releases smaller than feature releases but larger than update releases.
•  Preserve compatibility with the overall JEP 223 version-string scheme.
• Make it easy for a developer or end user to figure out how old a release is so that they can judge whether to upgrade it to a newer release with the latest security fixes and, possibly, additional features.
• Provide a way for an implementor to indicate that a release is part of a series of releases for which the implementor offers long-term support.
• Provide a way for an implementor to include and display an additional, implementor-specific version string in order to align a release with related products.

Version numbers:

$VNUM — The first four elements are interpreted as follows:

$FEATURE.$INTERIM.$UPDATE.$EMERG

$FEATURE — The feature-release counter, incremented for every feature release regardless of release content. Features may be added in a feature release; they may also be removed, if advance notice was given at least one feature release ahead of time. Incompatible changes may be made when justified. (Formerly $MAJOR.)

$INTERIM — The interim-release counter, incremented for non-feature releases that contain compatible bug fixes and enhancements but no incompatible changes, no feature removals, and no changes to standard APIs. (Formerly $MINOR.)

$UPDATE — The update-release counter, incremented for compatible update releases that fix security issues, regressions, and bugs in newer features. (Formerly $SECURITY, but with a non-trivial incrementation rule.)

The fifth and later elements of version numbers are reserved for use by downstream consumers of the JDK code base. The fifth element may be used to, e.g., identify implementor-specific patch releases.

This is how the elements will look like under the six-month release model 

• $FEATURE is incremented every six months: The March 2018 release is JDK 10, the September 2018 release is JDK 11, and so forth.
• $INTERIM is always zero, since the six-month model does not include interim releases. We reserve it here for flexibility, so that a future revision to the release model could include such releases and say that JDK $N.1and JDK $N.2 are compatible upgrades of JDK $N. As examples, the JDK 1.4.1 and 1.4.2 releases were, in essence, interim releases, and would have been numbered 4.1 and 4.2 under this scheme.
• $UPDATE is incremented one month after $FEATURE is incremented, and every three months thereafter: The April 2018 release is JDK 10.0.1, the July release is JDK 10.0.2, and so forth.

In short, “this scheme will often define version numbers that are not much different from what the JEP 223 scheme would have defined.” 

Read the entire announcement here.