RFR [9] Modular Source Code

[Alan Bateman]

On 15/08/2014 09:49, Magnus Ihse Bursie wrote:
> These are indeed the single most significant changes to the build 
> system since the "new" build system was introduced.
Indeed, some of us have been referring to this as the "new new build". 
As I recall there was a tail of issues and clean-ups for the JDK 8 "new 
build" and it will be the case here too. So if there aren't any blocking 
issues then I think the best thing is to work on those in jdk9/dev once 
the changes get there, otherwise I suspect we will iterate on this for a 
long time (and as I'm sure you can appreciate, it is painful to have to 
keep thousands of lines of make file changes in a side forest while the 
main line churns).

> :
>
> * When the source code has moved, especially the native libraries, 
> most of the specific INCLUDE and EXCLUDE statements are, or should be, 
> unnecessary. Nevertheless, there are still several occasions of such 
> statements. In some cases, it seems like dead code that can (and 
> should) be removed. But in some cases, I believe it is an indication 
> that the source code has still not yet been moved to a suitable 
> location. I believe the end goal with this shuffling regarding native 
> library source code is that there should be a one-to-one 
> correspondance between compiled native library and source code 
> directory. This is now indeed the case for 99% of the libraries, but 
> there are still some exceptions.
I assume you are referring to the rename of src/solaris to src/unix, 
something that was long overdue in the jdk repository. The intention is 
that eventually each area will go through their source files in 
src/$MODULE/unix and move any source files that are Linux, Solaris or OS 
X specific to the appropriate src/$MODULE/$OS tree. We've done it for a 
few libraries (such as libnio) so several EXCLUDE_FILES are already 
removed, the remainder of the exceptions will happen in time.


> :
>
> * Finally, I'm also not entirely happy with the placement of 
> modules.xml in the root directory. Erik has told me that the intention 
> is that this file will ultimately be created dynamically at build 
> time, and when that happens, it will just be a build by-product which 
> can be placed elsewhere. If this is indeed the case, I can live with 
> some temporary extra cluttering of the top-level directory
The top-level directory is intentional. It's not worth getting hung up 
on it because it is temporary (as noted in the JEP) and so will go away 
once we are further down the road on having a module system in JDK 9.

-Alan.