On 10/17/17 12:20 PM, Martin Buchholz wrote:
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!
The add-exports for jdk.compiler is not specific to the bootstrap process,
it is needed for any copy of javac, and is a consequence of design decisions
made (or not made) long, long ago in the JDK 5 timeframe. And yes, it
would be nice to eventually get rid of this.
-- Jon
