RFR  Modular Source Code
erik.joelsson at oracle.com
Wed Aug 13 12:11:18 UTC 2014
I should probably write something about the rather extensive changes to
the build logic in this patch.
As the source gets organized around modules, it made sense to also
organize the build more around modules. In this patch, the makefiles
have in large parts been split into module specific files and the top
level targets are oriented around modules. This means the top level
targets are much more fine granular than currently in JDK 9.
Another difference is that the top level targets are now able to run
concurrently, to give more opportunity for utilizing multiple cpus. In
JDK 9, the build moves sequentially through each repository, in a given
order, now make is free to run more things in parallel. This makes the
build faster, at least on beefy hardware. The drawback is that the build
log gets a bit more confusing. When something fails, it won't interrupt
other building threads at once, so the actual failure may be further up
the log (even further than before). I have found that searching for
"Error 2" is a good way to find the real failure. Another consequence is
that the build time summary at the end only displays total time as there
is no good definition for how much time was spent in each repository
A summary on the new targets:
Does pretty much the same as before. It compiles everything but does not
build all jars or create images.
Builds everything, including jars, images and docs. Also runs a
verification tool on the java classes which will point out any broken
Same as before
Builds the hotspot repository, like before.
Builds all the documentation, including javadoc.
Builds just the javadoc. This target has very few prerequisites so
provides a fast way to just build javadoc.
Runs all source code generation steps.
Compiles all java classes.
Other similar targets are libs, launchers, gendata and copy
Compiles everything in the java.desktop module (and its dependencies),
both java and native code. Works for any module name.
Compiles the java classes in java.desktop (and its dependencies). Works
for any module name (and -gensrc, -libs, -launchers, -gendata, -copy)
In addition to this, the suffix -only can be added to any target to
disable the prerequisites for it. Using this is not recommended but it
may save time when doing certain incremental builds and you are in a
For incremental builds, sjavac can be used and works reasonably well
(configure --enable-sjavac). Work is in progress on making it work even
better. The old workaround JDK_FILTER=package/to/compile is still working.
The clean target is still oriented around repositories, mostly because
the build output is still in large parts repository oriented. This is
something we hope to improve later.
On 2014-08-12 16:10, Chris Hegarty wrote:
> This is a review request for the Initial changes for JEP 201: Modular Source Code .
> There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the To section of this mail, and they will help address any comments arising from this review request.
> For the purposes of review, the actual source file moves have been omitted from the webrev below, with the exception of any source file that has a change to it’s actual content. The new location of the source files can be determined from JEP 201  and JEP 200 "The Modular JDK" , or by browsing the staging forest .
> Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev..
>  https://bugs.openjdk.java.net/browse/JDK-8051619
>  https://bugs.openjdk.java.net/browse/JDK-8051618
>  http://hg.openjdk.java.net/jigsaw/stage
More information about the build-dev