Two Java feature releases per year: Oracle proposes new time-based model
© Shutterstock / Levitskaya
Java is without a doubt one of the most beloved programming languages (if not *the* most beloved). However, there’s something that bothers even the most loyal users — the wait for a new version is too long. Things are about to change.
Earlier this month, we talked with Java Champion Stephen Colebourne about Java 9, Project Jigsaw and what he’d like to see in Java 10. “I hope Java 10 will arrive a lot faster than Java 9,” Stephen said — this came as no surprise. Many users believe that the wait for a new version is too long.
Now that Java 9 is fast approaching, users might wonder how much time they have to wait until the next version. As it turns out, the historical feature-driven release model is about to become …well…history.
Oracle proposes to increase the release cadence of Java SE to every six months
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.”
In retrospect, a two-year release cadence is simply too slow. To achieve a constant cadence we must ship feature releases at a more rapid rate. Deferring a feature from one release to the next should be a tactical decision with minor inconveniences rather than a strategic decision with major consequences.
That’s fast enough to minimize the pain of waiting for the next train yet slow enough that we can still deliver each release at a high level of quality, preserving Java’s key long-term values of compatibility, reliability, and thoughtful evolution.
Post-Java 9 plans
This is how the new model looks like:
- Feature releases can contain any type of feature, including not just new and improved APIs but also language and JVM features. New features will be merged only when they’re nearly finished, so that the release currently in development is feature-complete at all times. Feature releases will ship in March and September of each year, starting in March of 2018.
- Update releases will be strictly limited to fixes of security issues, regressions, and bugs in newer features. Each feature release will receive two updates before the next feature release. Update releases will ship quarterly in January, April, July, and October, as they do today.
- Every three years, starting in September of 2018, the feature release will be a long-term support release. Updates will be available for at least three years and quite possibly longer, depending upon your vendor.
What’s the difference between the new model and the old one? According to Mark Reinhold, the difference is that “there will be many more opportunities to deliver innovation. The six-month feature releases will be smaller than the multi-year feature releases of the past, and therefore easier to adopt. Six-month feature releases will also reduce the pressure to backport new features to older releases, since the next feature release will never be more than six months away.”
The version strings of feature releases will be of the form $YEAR.$MONTH, he added. The March 2018 release will be 18.3, and the September long-term support release will be 18.9.
This proposal will, if adopted, require major changes in how contributors in the OpenJDK Community produce the JDK itself.
Developers, users, and enterprises that rely upon Java will be affected but this proposal is meant to “help Java remain competitive for many years to come.”
“‘Missing a train’ with a feature that is not quite ready means only a six-month delay whereas before it could mean years”
We talked with Donald Smith, Senior Director of Product Management for Java SE at Oracle, about the proposal and its implications.
JAXenter: As OpenJDK binaries become the primary channel for developers to access the latest innovation in the Java SE platform, the Oracle JDK will remain as a long term support (LTS) offering for Oracle’s commercial and support customers. How did you reach this conclusion?
Donald Smith: The discussion is around increasing the release cadence of Java SE — so new language, library, and VM changes can be introduced more quickly — without disrupting those enterprises who wish to take a conservative approach to updates. The proposal we’re making strikes that balance and uses a “LTS” model that’s popular with many open source platform projects.
JAXenter: Oracle is planning to open source a number of internal development projects — including Java Flight Recorder — after proposing and discussing with OpenJDK contributors. Could you give us some names?
Donald Smith: Our intent is that transitioning between OpenJDK and Oracle JDK binaries should be seamless, and that implies there should be no feature differences at all. Although it would be exciting to offer a list of projects we would like to include, we want to do so through the normal OpenJDK processes by discussing with other potential contributors first.
JAXenter: Why is moving faster more important now than ever? How will the feature releases work and how can you make sure that quality doesn’t decrease?
Donald Smith: The application development market has shifted. The norm is to have time-based release models for platforms. The new model will encourage quality because “missing a train” with a feature that is not quite ready means only a six-month delay whereas before it could mean years. As an ecosystem, we need to shift the meaning of these biannual releases simply as “feature release” instead of a “major” release and the (now, hopefully) historical significance of those.
JAXenter: Some people have complained about that fact that Java 9 was delayed due to Project Jigsaw. Does this proposal have to do with the delayed release? Is Oracle indirectly admitting that they “made a mistake” by shipping Java 9 three and a half years after Java 8?
Donald Smith: The cadence of “major” releases of Java since 1.4 is just over three years, so Java SE 9 is not really an outlier. The application development market has shifted over the past several years making it easier for developers to build, test and deploy applications. Continuous integration and continuous deployment tools make it easier to introduce new features into production. Jigsaw will help that even further as it will help developers to avoid “jar hell” going forward.
JAXenter: What is the worst-case scenario? How will Oracle prepare for the “bumps in the road?”
Donald Smith: We’ve brought proposals to the respective JCP and OpenJDK community for discussions, and will be spending the next several weeks through JavaOne and JAX London talking to the broader ecosystem. The best way to prepare is to discuss the plans with all the stakeholders and be adaptive to feedback.