RFR: JDK-8189094: Change required boot jdk to JDK 9

[Jonathan Gibbons]

On 10/17/17 12:20 PM, Martin Buchholz wrote:
> On Tue, Oct 17, 2017 at 10:10 AM, Alan Bateman <Alan.Bateman at 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