On 2017-10-16 15:12, Erik Joelsson 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
This is a quite complex change. It's a bit unfortunate that we have to
make these kinds of changes to use JDK 9 as a boot JDK. Anyway, that's
the way it is.
A couple of remarks:
* In boot-jdk.m4, please update the comment as well:
# When compiling code to be executed by the Boot JDK, force jdk8
compatibility.
- BOOT_JDK_SOURCETARGET="-source 8 -target 8"
+ BOOT_JDK_SOURCETARGET="-source 9 -target 9"
* In JavaCompilation.gmk:
+ # exist yet, is in it.
+ $$(foreach d,$$($1_SRC), \
You can add a space after the comma with no ill effects.
- $$(eval $$(call FillCacheFind,$$($1_SRC)))
+ $$(eval $$(call FillCacheFind, $$(wildcard $$($1_SRC))))
Should not the $(wildcard) filtering be done in the FillCacheFind
function? It seems reasonable that it should not complain with an error
if you give it a non-existing directory.
- $1_ALL_SRCS += $$(foreach s, $$($1_SRC), $$(call CacheFind, $$(s)))
+ $1_ALL_SRCS += $$($1_EXTRA_FILES) $$(foreach s, $$($1_SRC), $$(if
$$(wildcard $$s), \
+ $$(call CacheFind, $$s)))
The same goes here. Any wildcard filtering should be done in CacheFind,
I think.
* In spec.gmk.in, the code for INTERIM_LANGTOOLS_MODULES_COMMA is
basically repeating the pre-existing macro CommaList. However, that is
only available in MakeBase.gmk. I'm not sure it's possible to use, but
maybe. It looks like there's a lot of hard-coded stuff in spec.gmk.in,
and maybe that is not the right place for it. Where are
INTERIM_LANGTOOLS_ARGS used?
* In jib-profiles.js:
You have no "var" declaration for the new boot_jdk_version etc. I'm not
too well-versed in javascript and it is probably quite legal not to, but
I think it's better style at least to keep it.
* Finally, $(BUILDTOOLS_OUTPUTDIR)/override_modules should be renamed
"interim_modules".
/Magnus
