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.
