RFR: JDK-8200083: Bump bootjdk used for JDK 11 at Oracle to JDK 10

Jonathan Gibbons jonathan.gibbons at oracle.com
Fri Apr 6 16:51:21 UTC 2018


On 4/6/18 2:16 AM, Andrew Dinn wrote:

> Hi Erik,
>
> On 05/04/18 18:57, Erik Joelsson wrote:
>> The intention of my second suggested patch was basically to keep
>> allowing JDK 9 in configure for a while but being pretty sure it would
>> stop working eventually. I don't like doing it that way. It's much
>> better with a clear fail early error in configure, but the first
>> suggested patch, that did just that, met such hard resistance and not a
>> single positive review.
> I am not sure the lack of positive reviews was an indication that no one
> felt positive about your suggestion. It's quite possible that many
> simply did not envisage the same pain as those who raised the negative
> reviews and so did not feel moved to demur.
>
> So, after reading the discussion here and assessing the implications of
> the different choices let me offer you a positive review. I believe that
> a clearly stated and applied N-1 policy is the best choice.

I think the N-1 policy should be more clearly stated as "last GA".

When we started work on JDK 11, JDK 10 had not yet shipped, and so it
was appropriate for JDK 11 to use JDK 9 as the boot jdk.  Now that JDK 10
has shipped, it becomes a candidate to be a boot JDK, and becomes
the most recent GA JDK version.

-- Jon
>
> I'll admit that I tended to that view anyway before the discussion
> started. Bootstrapping, especially in the context of a language runtime,
> is actually much more complex than it appears. Contrary to naive
> expectation, especially by those who are only tangentially involved in
> making it happen, it never really goes away. The need to bootstrap new
> capability keeps on coming back to bite us (whether individually or,
> occasionally and rarely, jointly) as the language and runtime evolve,
> requiring continual magic to allow a step up -- or occasionally sideways
> or, one hopes rarely, backwards -- from one level of functionality and
> abstraction to the next.
>
> The trade-off between keeping the ladders you climbed up on in place or
> whisking them away from under your newly assumed seat of superiority has
> to recognise: firstly, that the cost of maintaining even a single layer
> of such scaffolding is often very high -- magic always really means a
> lot of hard, behind the scenes work; secondly, that the requirement to
> be able to pile such layers on top of each other frequently produces a
> very rickety and fragile platform at the apex. If the price of stability
> is that a few users may need to retake some of those steps slowly, one
> at a time then I am for stability.
>
> 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 build-dev mailing list