On Tue, Oct 17, 2017 at 10:10 AM, Alan Bateman <alan.bate...@oracle.com> wrote:
> On 17/10/2017 17:53, Martin Buchholz wrote: > > I tried to figure out how this patch actually works. At first I thought > we were "shading" (renaming all the packages in the source files) but now I > think we're merely renaming the modules by appending ".interim" to the > names. But that looks like cheating to me - we're not allowed to have > multiple modules containing the same packages, but are getting away with it > because the runtime happens to never look at the (unused) original jdk9 > modules? > > The patch uses `--limit-modules` to limit the observability of modules and > prevent the jdk.compiler module in the boot JDK from being resolved. If the > boot JDK were to resolve jdk.compiler (in its own run-time image) and > jdk.compiler.interim on the module path then you would end up with two > modules containing the same classes mapped to the app class loader, can't > do that. > Wow, --limit-modules sure is a good trick. So now we have two possible replacements for the demise of -Xbootclasspath/p: --patch-module --limit-modules combined with renamed replacement modules Looking at the patch I see +INTERIM_LANGTOOLS_ADD_EXPORTS := \ + --add-exports java.base/sun.reflect.annotation=jdk.compiler.interim \ + --add-exports java.base/jdk.internal.util.jar=jdk.jdeps.interim \ + --add-exports java.base/jdk.internal.misc=jdk.jdeps.interim \ + # so the interim compiler is accessing JDK internals - isn't this what we're telling users NOT to do? Especially when this is the internals of the boot jdk - You can't bootstrap jdk10 with any compliant implementation of Java SE 9! The jdk bootstrap process should be setting a good example!
