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

Andrew Dinn adinn at redhat.com
Fri Apr 6 09:16:32 UTC 2018


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'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