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

Rob McKenna rob.mckenna at oracle.com
Thu Jan 25 18:40:22 UTC 2018

Hi Martin,

On 25/01/18 10:19, Martin Buchholz wrote:

There is enough interest in jdk9 that at least minimal community maintenance should be possible.

Neither Google nor I personally are currently willing to step up to being the official maintainer of jdk9u, but I have some fixes to contribute if a maintainer is willing to accept them. The obvious candidates for jdk9u official maintainer are Andrew Haley (Red Hat) and Dmitry Cherepanov (Azul). jdk8 and jdk10 are also likely to need new maintainers starting in 2018-09. Start planning now. jdk9 went through a long period where bug fixes were discouraged or deferred. jdk9 rampdown started in 2017-01. Some engineers (including myself) tagged some bugs with the label "9-bp". I created a simple JIRA filter for all such bugs - https://bugs.openjdk.java. net/issues/?filter=33680 . There was never any vehicle for those jdk9 fixes to be delivered because there was never an actual non-security update jdk9 release. It's the first time such a thing has happened for a major jdk release.

As per: http://openjdk.java.net/projects/jdk-updates/approval.html you can add a -critical-request label to the bugs in order to get them included into an update. (so 9-critical-request in this instance)

Unfortunately this process was only announced at the beginning of last November which left slightly less than 2 months for the requests to get into 9.0.4 but I'm hoping the process will solve this problem for future releases.

-Rob

jdk8 was released 4 years ago. The next release suitable for risk-averse adopters would seem to be one of the early bug fix releases of jdk11 expected in 2019. It's a long time. On Thu, Jan 25, 2018 at 9:36 AM, Andrew Dinn <adinn at redhat.com> wrote: > On 25/01/18 17:28, Alan Bateman wrote: > > On 25/01/2018 16:46, Andrew Haley wrote > >> : > >> This is ridiculously hostile behaviour: to break a bunch of things > >> in OpenJDK, do a release, and then immediately drop the project > >> on the floor before giving anyone a chance to fix what is broken. > >> Really, I would have expected better than this. > >> > >> I guess I'll have to be the project maintainer for long enough to > >> commit the necessary fixes so that jdk9u works for all ports, not > >> just the ones that Oracle ships. > >> > > 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. > > No, of course it was not deliberate breakage. The deliberate action we > are concerned about would be simply walking away from the mess afterwards. > > > This may be something that the establishment of the vulnerabilities > > group will help with. Alternatively maybe the JDK Update maintainers > > could just approve the changes needed to get the ports aligned and leave > > it at that. If someone steps up to maintain the JDK 9 updates going > > forward then they could tag a new release that includes the changes. > Well, of course, this is a poster-child level argument for getting the > vulnerabilities group sorted out asap. But that's a secondary question > right now. The important question still remains what to do about a tree > that has been left in a half-baked state. I think it would make a great > deal of sense for the existing patches which are known to resolve the > problem to be pushed to the current tree. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander >

More information about the jdk-updates-dev mailing list