RFR: JDK-8189094: Change required boot jdk to JDK 9

[Alan Bateman]

On 16/10/2017 16:41, Martin Buchholz wrote:
> The difficulties encountered trying to run langtools10 in a jdk9 suggests
> that the jdk9 module model is too restrictive.  I've long lobbied for
> treating langtools as just another collection of ordinary programs that
> happen to be written in java and should not need special support from the
> host jdk.
>
> Many people will want to run modified langtools.  Shouldn't replaceability
> of any module be one of the goals of the module system?
>
The module system already supports ways to replace/override a module 
(via the upgrade module path and the --upgrade-module-path option) or 
patch/augment a module to override or add classes/resources 
(--patch-module).

At the same time, it supports the ability to tie a group of closely 
connected modules with integrity hashes to prevent accidental mixing of 
modules from different builds or releases.

The issue that Erik has been wrestling with is that a module can't be 
both upgradeable and non-upgradable at the same time. If they 
upgradeable then you risk someone creating a run-time image with 
jdk.compiler and jdk.javadoc modules from different JDK releases - it's 
not supportable of course. If you continue with them as non-upgradeable 
modules then you need to do something special in the JDK build to 
combine a boot JDK with newer versions of the modules and this is what 
Erik is doing. There are a couple of ways to do that, like putting the 
classes for these modules on the class path and limiting observability 
with --limit-modules. The alternative is to put the code into modules 
with new names, Erik's patch favors that approach.

-Alan.