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

dalibor topic dalibor.topic at oracle.com
Fri Jan 26 19:19:21 UTC 2018

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.

That being said, that's not a hard requirement. So we probably could have a set of unreleased patches in the forest waiting for someone else to step to maintain the forest and release them.

But what complicates things in the interim time between the last Oracle planned Oracle-led update (9.0.4) and the official end of public life for an OpenJDK update release series led by Oracle (March 2018 for JDK 9 Updates) is that we have simultaneous Oracle and OpenJDK releases that are supposed to converge, rather than diverge over time as long as they are led by Oracle.

So ideally, we'd have no actual [0] JDK 9 Update releases in that interim phase before someone else steps up once Oracle steps down, as the only reason to have one would be a hypothetical future Security Alert.

In that hypothetical scenario with unreleased patches lurking around in the forest things could become very complicated very quickly, for example if such patches have unforeseen side-effects on platforms that weren't tested at the time of their inclusion into then OpenJDK 9u forest.

To make a long story short, I think that we just needed (and I think may still need) a bit of time to think through the implications of an unforeseen situation (last planned Oracle unexpectedly build breaking downstream builds).

Please don't assume that's a deliberately hostile act - we just have to navigate a more complicated problem space than might be apparent immediately. I'm sure that it's similarly unappealing to everyone involved to have to deal with this kind of problems after a release as it is to you to have to wait on the patches fixing these regressions to finally make it in. I wish we had foreseen this situation earlier and avoided the resulting inconvenience.

cheers, dalibor topic

[0] Tagging additional 'source code only' 'builds' of 9.0.4 rather then new releases might work, since I assume that these kind of post CPU regression fixes would typically address build failures on platforms not already provided on jdk.java.net.

-- <http://www.oracle.com> Dalibor Topic | Principal Product Manager Phone: +494089091214 tel:+494089091214 | Mobile: +491737185961 tel:+491737185961

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

More information about the jdk-updates-dev mailing list