Accelerating the JDK release cadence

Stuart Monteith stuart.monteith at
Mon Sep 18 15:10:35 UTC 2017

This is a welcome development. One of my wishes, working on Aarch64, would
be for all architectures to be at parity on release. With open
build-and-test infrastructure, and the more frequent releases, this looks
far more achievable. In the worst case, a well maintained architecture
would be 6 months behind. In that scenario I wonder whether different
architectures would have different ideas of long-term-support releases.

Will there ever be a JDK 9u? The update releases are normally created soon
after a major release.

Best regards,

On 6 September 2017 at 15:49, <mark.reinhold at> wrote:

> Over on my blog today I've argued that Java needs to move forward faster.
> To achieve that I've proposed that the Java SE Platform and the JDK shift
> 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:
> Here are some initial thoughts on how we might implement this proposal
> here in the OpenJDK Community.  Comments and questions about both the
> proposal and its implementation are welcome on this list.
> Rather than create a brand new "JDK $N" Release Project every six months,
> I suggest that we create a single long-running "JDK" Release Project to
> host the main-line code base and produce the feature releases.  Similarly,
> let's create a single long-running "JDK Updates" Project to produce the
> update releases, for the most recent feature release and the current
> long-term support release.
> Two long-running Projects will save some administrative overhead, and also
> eliminate the confusion that regularly arises when someone is a Committer
> to JDK $N but not JDK $N + 1.  (We could consider just one long-running
> Project, but two makes more sense since since the two types of releases
> will have different policies, content, schedules, and leadership.)
> The new JDK Project will run a bit differently than the past "JDK $N"
> Projects:
>   - The main development line will always be open but fixes, enhancements,
>     and features will be merged only when they're nearly finished.  The
>     main line will be Feature Complete [1] at all times.
>   - We'll fork the main line into a release-stabilization branch three
>     months before the GA date of the next feature release.  That branch
>     will immediately be in Rampdown Phase 1 [2], enter Rampdown Phase 2
>     [3] a month later, and then enter the Release Candidate phase [4] a
>     month after that.  (Whether the branch is another repository or an
>     actual Mercurial branch is a detail we can figure out later.)
>   - We'll continue to use the JEP Process [5] for new features and other
>     significant changes.  The bar to target a JEP to a specific release
>     will, however, be higher since the work must be Feature Complete in
>     order to go in.  Owners of large or risky features will be strongly
>     encouraged to split such features up into smaller and safer parts, to
>     integrate earlier in the release cycle, and to publish separate lines
>     of early-access builds prior to integration.
> The JDK Updates Project will run in much the same way as the past "JDK $N"
> Updates Projects, though update releases will be strictly limited to fixes
> of security issues, regressions, and bugs in newer features.
> Related to this proposal, we at Oracle intend to make a few changes in
> what we do:
>   - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [6], to
>     make it easier for developers to deploy Java applications to cloud
>     environments.  We'll initially publish OpenJDK builds for Linux/x64,
>     followed later by builds for macOS/x64 and Windows/x64.
>   - We'll continue to ship proprietary "Oracle JDK" builds, which include
>     "commercial features" [7] such as Java Flight Recorder and Mission
>     Control [8], under a click-through binary-code license [9].  Oracle
>     will continue to offer paid support for these builds.
>   - After JDK 9 we'll open-source the commercial features in order to
>     make the OpenJDK builds more attractive to developers and to reduce
>     the differences between those builds and the Oracle JDK.  This will
>     take some time, but the ultimate goal is to make OpenJDK and Oracle
>     JDK builds completely interchangeable.
>   - Finally, for the long term we'll work with other OpenJDK contributors
>     to establish an open build-and-test infrastructure.  This will make
>     it easier to publish early-access builds for features in development,
>     and eventually make it possible for the OpenJDK Community itself to
>     publish authoritative builds of the JDK.
> So ... that's a lot of proposed change, and there are (obviously!) many
> details to work out.  Comments?  Questions?
> - Mark
> [1]
> [2]
> [3]
> [4]
> [5]
> [6]
> [7]
> products/index.html
> [8]
> control/index.html
> [9]

More information about the discuss mailing list