RFR: JDK-8189094: Change required boot jdk to JDK 9
Alan.Bateman at oracle.com
Mon Oct 16 17:18:19 UTC 2017
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
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.
More information about the build-dev