Boot-JDK policy (original) (raw)
mark.reinhold at oracle.com mark.reinhold at oracle.com
Wed Apr 18 18:53:10 UTC 2018
- Previous message: Draft JEP: Deprecate pack200, unpack200 tools and related APIs.
- Next message: State of jdk-submit?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
// 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
- Previous message: Draft JEP: Deprecate pack200, unpack200 tools and related APIs.
- Next message: State of jdk-submit?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]