RFR [9] Modular Source Code

[Chris Hegarty]

Thanks for the explanation Erik.

I have taken a pass over the changes, and they look ok to me ( I am 
happy to be listed as a reviewer ). I also did several build and test 
runs on Solaris, Linux, Max OSX, and Windows. All look good.

I am seeing, in some cases, about a 20% reduction in image build times 
on an 8 core i7, running Linux x86.

One question; Are there any new requirements on build systems as a 
result of these changes?

-Chris.

On 13/08/14 13:03, Erik Joelsson wrote:
> 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
> anymore.
>
> A summary on the new targets:
>
> make [default]
> Does pretty much the same as before. It compiles everything but does not
> build all jars or create images.
>
> make all
> Builds everything, including jars, images and docs. Also runs a
> verification tool on the java classes which will point out any broken
> module boundaries.
>
> make images
> Same as before
>
> make hotspot
> Builds the hotspot repository, like before.
>
> make docs
> Builds all the documentation, including javadoc.
>
> make docs-javadoc
> Builds just the javadoc. This target has very few prerequisites so
> provides a fast way to just build javadoc.
>
> make gensrc
> Runs all source code generation steps.
>
> make java
> Compiles all java classes.
> Other similar targets are libs, launchers, gendata and copy
>
> make java.desktop
> Compiles everything in the java.desktop module (and its dependencies),
> both java and native code. Works for any module name.
>
> make java.desktop-java
> 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
> terrible hurry.
>
> 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.
>
> /Erik
>
>
> On 2014-08-12 16:10, Chris Hegarty wrote:
>> This is a review request for the Initial changes for JEP 201: Modular
>> Source Code [1].
>>
>> 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 [1] and JEP 200 "The
>> Modular JDK" [2], or by browsing the staging forest [3].
>>
>> Webrevs:
>>   http://cr.openjdk.java.net/~chegar/8054834/00/
>>
>> 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..
>>
>> -Chris.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8051619
>> [2] https://bugs.openjdk.java.net/browse/JDK-8051618
>> [3] http://hg.openjdk.java.net/jigsaw/stage
>