From translator

Recently, a couple of important events happened in the Java world: Mark Reinhold published a letter in which he suggested moving to the semi-annual Java release schedule, and this was followed by a message from Oracle, where they offer a number of major changes in the work on OpenJDK:

• Starting with JDK 9 GA, Oracle will release OpenJDK builds under the GPL license.
• Java SE will move to a permanent release schedule (Mark's letter)
• Oracle will introduce earlier commercial features (like Java Flight Recorder) in OpenJDK
• Oracle will work with other OpenJDK developers to provide a modern, complete and affordable environment.

Although the commercial version of Oracle JDK will remain, the company's goal will be to make it fully compatible and interchangeable with OpenJDK (until the end of 2018).

As I see it, this is a very important and necessary step for Java as a platform. Below, I suggest translating Mark's letter, which explains how the new release schedule will work.

Moving Java forward faster

For more than 20 years, the Java SE platform and JDK have been moving forward in large, irregular and unpredictable steps. Each feature-release was determined by some main feature and the release schedule changed - sometimes more than once! - to adjust to the schedule for the development of this feature.

This approach made possible the inclusion of new features in the release with the highest quality, after a thorough review and testing. The disadvantage of this approach, however, is that smaller API, language and platform features can only be included in the final release when the main feature is ready.

It was a reasonable compromise for decades before and after the turn of the century, when competitors to Java were just a few platforms that were developing at the same slow pace. Nowadays, however, Java competitors are developing much faster.

In order for Java to remain competitive, we must not just move forward - we must move fast.

Train again

Five years ago, I was thinking in this blog about the difference between developers who prefer fast innovation, and an enterprise that prefers stability, as well as the fact that everyone, in fact, prefers regular and predictable releases.

In order to solve the problems of those and others, I then suggested that we should switch from the historical model of releases, where the release is determined by a set of features, to the “train” model, when the release goes strictly on schedule, every two years. With this approach, the development may not adapt to the release and engage in innovation, and the release, regardless of the development, has a permanent schedule. Any feature, big or small, is included in the release only when it is (almost) completely ready. If the development of features does not have time for the current release "train" - it is unpleasant, but not the end of the world, because The next "train" to go strictly on schedule.

The biennial “train” model looked good in theory, but it proved its inoperability in practice. It took us an additional 8 months for Java 8 to close critical security issues and complete the Lambda project , and this was preferable to putting off the lambda for two years. Initially, we even planned Java 9 as a 2.5-year release to include Project Jigsaw there , so as not to delay it 18 months before the next “train”. But in the end, it took us another year to finalize, and Java 9 will be released only this month, 3.5 years after Java 8.

Looking back, it can be said that the two-year release cycle is simply too slow. To achieve a regular schedule, we must release releases much more often. Moving a feature to the next release should be a tactical solution with a minimum of inconvenience, instead of a global solution with serious consequences.

So, my suggestion: let's release releases every six months .

This is fast enough to avoid problems from waiting for the next release, but slowly enough so that releases can remain of high quality.

Sentence

Inspired by the example of the release schedule of other platforms and operating systems, I propose, after the release of Java 9, to switch to a strict, regular release schedule with a new feature release every six months, an update release every quarter and an LTS (long term support) release every three years .

• A feature release can contain any features, including not only new or updated APIs, but also features of the language and JVM. New features will be included in the release then in the final stages, so the current release should be feature-complete at any time. Feature releases will be released twice a year, in March and September, starting in March 2018 .
• The update release will be strictly limited to fixes for security issues, regression bugs, and bugs in new features. Each feature release will have two update releases. Update releases will be issued quarterly in January, April, July and October .
• Every three years, starting in September 2017 , the feature release will become the LTS release . Updates for LTS releases will be available for at least three years, and possibly longer, depending on the supplier.

With this model, the overall rate of change should be the same as today. However, the key difference is that JDK developers will have much more opportunities to release new features. The semi-annual feature release will be less than a multi-year release with a bunch of new features in the past, and therefore it will be easier to switch to it. A semi-annual release will also reduce the difficulty of porting code to old releases (backport), since the difference between them will not exceed 6 months.

Developers who prefer innovations and new features will be able to use new feature releases or the latest available update releases. They will be able to package applications into Docker containers, or any other type of container, indicating the exact version of Java they need. With this approach, because A new release of Java and an application can be easily tested for compatibility using modern CI / CD pipelines, the transition to a new release will be easy.

Enterprise developers who prefer stability so that they can run several large applications on a single, common Java release will be able to use LTS instead of feature releases. They will also be able to schedule updates to the next LTS strictly on schedule, every three years.

To navigate new releases with a strict schedule and to easily understand when a particular release was released, the release version would look like $ YEAR. $ MONTH. That is, the next March release will be 18.3, and the September LTS will be 18.9.

Effects

This proposal, if accepted, will require major changes in the way contributors in the OpenJDK Community directly produce the JDK. I laid out a number of thoughts on this. This process will be much simpler if we are able to reduce the overheads created by the Java Community Process, which is in charge of the development of the Java SE platform; my colleagues Brian Getz and George Sub have already raised this issue for discussion with the JCP Executive Committee .

This offer will, after all, affect every developer, user, and company that rely on Java. It will also, if successfully implemented, help Java remain competitive, but still rely on a set of values ​​such as backward compatibility, reliability, and thoughtful development for many years to come.