<div dir="ltr">Obviously y'all have the engineering resources to do any shoe-horning necessary to get jdk9 to run jdk10 langtools.  But consider that this is the sort of thing users will be doing as well.  It seems very natural to decouple langtools from its host jdk; at Google we often run langtools hosted in the "wrong version" JDK.  I would choose a name other than "interim" which suggests what you're doing is only for bootstrapping.  Imagine that the langtools10 will become an independent modular artifact hosted on Maven Central.<div><br></div><div>I'd like to be able, at runtime, to decide whether to use jdk N langtools or jdk N+1 langtools (or special errorprone-enabled langtools, etc...), and have a minimal-effort solution that allows that to happen.  Java's bootstrap process should be a poster child for the promise of modularity, that I could copy to enable my runtime choices.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 16, 2017 at 10:18 AM, Alan Bateman <span dir="ltr"><<a href="mailto:Alan.Bateman@oracle.com" target="_blank">Alan.Bateman@oracle.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 16/10/2017 16:41, Martin Buchholz wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The difficulties encountered trying to run langtools10 in a jdk9 suggests<br>
that the jdk9 module model is too restrictive.  I've long lobbied for<br>
treating langtools as just another collection of ordinary programs that<br>
happen to be written in java and should not need special support from the<br>
host jdk.<br>
<br>
Many people will want to run modified langtools.  Shouldn't replaceability<br>
of any module be one of the goals of the module system?<br>
<br>
</blockquote></span>
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).<br>
<br>
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.<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
-Alan.<br>
</font></span></blockquote></div><br></div>