JDK 18.3 Early Draft Review available for download
© Shutterstock /Zerbor
Mark Reinhold, the Chief Architect of the Java Platform Group at Oracle, has recently proposed the schedule for JDK 18.3. The milestone definitions are the same as for JDK 8 — there will be no “Feature Complete” milestone though. Early Draft Review is now available for download and will close on November 23rd.
You can now download the Early Draft Review for JDK 18.3. The closing date is November 23, 2017.
Remember: “The public’s participation in Early Draft Review is an important part of the process since in the past comments from the public have raised fundamental architectural and technological issues that have considerably improved some Specifications.”
After the Early Draft Review period has ended, the Expert Group can make any additional changes to the draft it deems necessary in response to comments before submitting the draft to the PMO for the next review.
Find out more about the JCP procedures here.
Update October 12, 2017
Mark Reinhold, the Chief Architect of the Java Platform Group at Oracle, announced in a message to the OpenJDK mailing list that the proposed schedule for JDK 18.3 is as follows:
2018/01/11 All Tests Run
2018/01/18 Rampdown Phase Two
2018/02/22 Final Release Candidate
2018/03/20 General Availability
— Mark Reinhold (@mreinhold) October 11, 2017
According to Reinhold, the milestone definitions are the same as for JDK 8.
There’s no “Feature Complete” milestone since, in the six-month model, every feature must be complete before it’s integrated. The main development line is, in effect, always feature complete. The set of features in the release contains all, and only, those features that are integrated ahead of Rampdown Phase One.
Reinhold added that he would soon propose a detailed definition of what it means for a feature to be “complete”. However, he did mention that the definition “will be along the lines of what the milestone has always meant for past releases: A complete feature includes, at the very least, all necessary code, specification text, and unit tests.”
If no objections are raised by October 18, 18:00 UTC “or if they’re raised and then satisfactorily answered,” the proposal will be adopted as the schedule for JDK 18.3 (“or whatever we wind up calling it”).
SAP’s Volker Simonis asked if this means that the JDK 18.3 repository “will be created (i.e. forked) just before “Rampdown Phase One” is entered” and wanted to know what’s the working model after the fork of JDK 18.3.
What will be the working model after the fork of jdk-18.3? Will bug fixes for 18.3 have to go to jdk-dev first and then backported to jdk-18.3 or can they be pushed right into jdk-18.3? In the latter case, will there be an automatic integration process of fixes from jdk-18.3 into jdk-dev?
“Or whatever we wind up calling it”: Is there still hope for the old numbering scheme?
Speaking of the old vs. new numbering scheme, this topic came up during the JAX London panel with Oracle’s Donald Smith, Daniel Bryant, Stephen Colebourne, Peter Lawrey and Martijn Verburg.
— JAXenter.com (@JAXenterCOM) October 11, 2017
(from left to right: Donald Smith, Peter Lawrey, Martijn Verburg, Stephen Colebourne, Daniel Bryant)
— JAX London (@jaxlondon) October 11, 2017
There was an interesting exchange of ideas with regard to the new numbering scheme — Stephen Colebourne said that he is dissatisfied with the proposal but that doesn’t come as a surprise: he recently wrote a plea “for sane Java version numbers such as 10, 11, 12”.
He believes that even though “the LTS release is important to Oracle and big business, it will be pretty unimportant to the community.” Furthermore, “a year/month scheme is unusual and unexpected.”
Stephen proposes that “versions should simply increase incrementally”:
March 2018 — v10
September 2018 — v11
March 2019 — v12
September 2019 — v13
and so on.
Read the entire plea here.