Boot-JDK policy

[mark.reinhold at oracle.com]

// New thread, explicitly about the policy rather than a code review

To summarize the discussion so far ...

To build JDK version N you need an earlier "boot" JDK, version N - k
for some k > 0, since javac is itself written in Java.

Historically we've used k = 1, meaning that to build the JDK currently
in development you need the most-recently GA'd version.

With the new six-month release cadence what value, or range of values,
should we allow for k?  Should we, e.g., set k = 2, meaning the GA'd
version before the most-recently GA'd version?  Should we vary k over
time so that it always refers to the most-recently GA'd LTS version?
Should we do something else entirely?

There are two main arguments in favor of minimizing k:

  - Limiting javac and related tools and APIs to the N - 1 or N - 2
    source version is reasonable.  Limiting these components to N - 5
    or N - 6, which is what a most-recent-LTS policy would sometimes
    imply, is not.  (That would mean, e.g., that javac could not
    leverage relevant new language features, such as pattern matching,
    until after JDK 17.)

  - This isn't just about the source version of javac, but also about
    the cost of maintaining the entire system in the face of other,
    sometimes dramatic, changes in the JDK.  The older the boot-JDK
    release, the more onerous this cost tends to be.  (We experienced
    this recently with JDK 9, which is modular but built with the
    non-modular JDK 8; removing the workarounds needed for that led
    to significant simplifications in JDK 10.)

The main argument in favor of maximizing k, perhaps even to encompass
the most recent LTS release, is that being able to bootstrap the build
with an older JDK is more convenient for some JDK developers, especially
for esoteric target architectures that sometimes fall behind.

The counterargument to that, of course, is that even for k = 1 the
necessary boot JDK is readily available for mainstream architectures,
and just because it might be EOL doesn't mean that it won't work.
It's not reasonable to burden developers who work on the mainstream
architectures -- which is most of them -- for the convenience of the
few who work on esoteric architectures.  Here I agree with Andrew Dinn:
"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."

Various compromises have been suggested, such as recommending k = 1 but
allowing, perhaps with warnings, some k > 1, or else treating some k > 1
as "best effort".  I agree with those who prefer clarity here -- being
vague about the boot-JDK version will just lead to confusion in the long
run, so we should just pick one.

On balance, unless someone has a new factor to bring to this discussion,
I propose that we keep k = 1, i.e., retain the historical N - 1 boot-JDK
policy.

- Mark