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

[Martin Buchholz]

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?


On Mon, Oct 16, 2017 at 6:12 AM, Erik Joelsson <erik.joelsson at oracle.com>
wrote:

> With JDK 9 released, it's high time to change the required boot jdk for
> building JDK 10. This time, the change wasn't as straight forward as it
> usually is.
>
> It's currently possible to use any of JDK 8, 9 or a recent build of 10 to
> boot the JDK 10 build. This support is however fragile. The most sensitive
> part is the building and running of the interim javac and javadoc tools,
> where we build the new JDK 10 versions of these tools, but -source/-target
> set appropriate for the boot jdk, so we can run them on the boot jdk when
> compiling the rest of the product.
>
> In the current build, we compile the java source files of the modules
> java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps in the legacy way,
> using -Xbootclasspath and not including any module-info.java files. We then
> run them by using the --patch-module argument. This means we are running
> the JDK 10 classes but using the module definitions of the boot jdk. This
> works for now, but when the JDK module definitions for any of these modules
> need to change, this model will start to break.
>
> In this patch I have tried to change this so we compile and run using JDK
> 9 module style modes. The big problem to overcome then is that
> jdk.compiler, and jdk.javadoc are not upgradeable. This means we can't
> compile new versions of these modules and override them in the boot jdk.
> This leaves us with two options: either run the interim classes in the
> unnamed module, or define a new set of interim modules, based on the
> existing modules but with new names. The first option seems simpler, but
> that would require maintaining legacy service provider definitions for
> these modules. So I chose the latter instead. The new module names have
> ".interim" as suffix.
>
> To generate the new modules, I copy the module-info.java files to a new
> gensrc dir and sed replace the module names. I also generate a new
> ToolProvider.java so that the default tools are taken from the interim
> modules.
>
> I've made sure that jrtfs.jar is generated with --release 8 to keep
> compatibility with JDK 8.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8189094/webrev.01
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189094
>
> /Erik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20171016/c0ac776f/attachment.html>