Future jdk9u updates & 9-critical-request (original) (raw)

Andrew Hughes gnu.andrew at redhat.com
Mon Jan 29 18:26:00 UTC 2018

On 26 January 2018 at 19:19, dalibor topic <dalibor.topic at oracle.com> wrote:

On 25.01.2018 18:31, Andrew Haley wrote:

On 25/01/18 17:28, Alan Bateman wrote:

I don't think anyone deliberately broke anything. I think it's just that 9.0.4 was a security release so the changes couldn't bake in jdk-updates/jdk9u.

Sure, I understand that it wasn't deliberate. However, the immediate tagging and tying-off of the branch was. The tagging serves to mark the corresponding source code for an OpenJDK release, so that was definitely deliberate, and as it should be. ;) The forest isn't actually tied off yet, as you can see when you look at http://hg.openjdk.java.net/jdk-updates/ - it'd be marked as 'READ ONLY' in that case. That's also as it should be, as we discussed earlier on this list with keeping 9u open for a qualified Committer to step up and maintain once we stop doing it. What I believe we've done for OpenJDK 6 and JDK 7 Updates was to let any such maintainer take over from a clean slate, i.e. with no unreleased patches stuck in the repository. I think it would have been simplest if we could have done the same for 9u, having a single point in time after the end of public updates when someone else steps up and maintains it going forward for however long or short they need to.

The main difference is that Oracle maintainership of OpenJDK 7 ended with a publicly developed update, u80, while OpenJDK 9 has concluded with a security update.

OpenJDK 9 has also had a much more contracted lifecycle than has been expected in the past, and is likely to remain a unique release in having a long development cycle - making it quite different from OpenJDK 8 - but a short release cycle. Transition from 8 to 9 is much more of an undertaking than I would expect 9 to 10 is going to be, and what we'll probably see the 9 and 10 releases being skipped in many cases, as part of transitioning between the two release cycles. As a result, there hasn't been anything like the run-up to its end-of-support deadline as there was with OpenJDK 6 and 7.

There also hasn't been much chance for any patches to build up. The repositories for 9.0.1 were late in appearing due to the transition to the jdk-updates project only happening after this release, leaving very little time for anything to be backported to 9 before 9.0.4. It's also now very hard to tell what backports have been requested and actually committed due to the move from an open process on the mailing list to tagging of bug requests, which not only takes time for people to adapt to, but also seems like a backwards step in terms of community involvement.

One of the problems here is the lack of a more open release process. At present, it goes:

  1. Release binaries
  2. Retro-actively request to add the sources for these binaries to OpenJDK

I'm not pointing fingers only at Oracle for this, because we've also ended up adopting this process with IcedTea and OpenJDK 6 & 7. It's difficult to deal with security releases any other way, because binaries have to be ready to go when the embargo is lifted. If the release is left open for discussion, you risk having binaries that don't match the source.

So I suspect the real problem here is the lack of feature updates in this new lifecycle, To compare 6 & 7 with 9 is comparing apples and oranges, because they operated under a completely different release process. If Oracle want to leave future maintainers with a "clean slate", there needs to be a concluding feature release i.e. something we can openly contribute to, as we did under 7 and 8. I would suggest this occurs in parallel with the first release of the next version, and is used as a point outside of security updates, to say "This is the last one of x. You need to be switching to x+1 over the next month to continue getting security updates.".

Andrew :)

Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com)

Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222

More information about the jdk-updates-dev mailing list