On 4/6/18 2:16 AM, Andrew Dinn wrote:
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.
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.
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