The role of submodules

[Mandy Chung]

On 3/28/13 1:51 AM, Erik Joelsson wrote:
> Hello,
>
> While working with the jigsaw build, I can't help but wonder what the 
> reason for the submodules concept is. In the old build, each area is 
> assigned a "MODULE", which isn't a full module name, but something 
> shorter. All artifacts produced in an area, like libraries and lib 
> files, automatically get copied to a sub directory of the submodules 
> outputdir. Then in the modularization step, the contents of these 
> submodules is copied to the final (real) modules according to a 
> configured pattern. (ex: base -> jdk.base, javac -> jdk.tools)
>

When we started the modules build, the module graph was not clean to 
begin with.  We grouped classes in a fine-grained module to allow us to 
do experimentation and fine-tuning the module graph by aggregating more 
than one small modules (submodules) into one.  It also makes it easier 
for us to determine any undesirable dependency across submodules that 
may become a non-issue when those submodules are relevant and grouped as 
a single module.

> Is there a reason to keep this model going forward, or can we assign 
> things their final module name directly in the new build? I would like 
> to minimize copying files around for no apparent reason if possible.

I don't see the need to keep the submodules and we can use the modules 
currently defined in the new build as you suggest as the module graph is 
looking good and clean.  One thing to keep in mind is that there will 
likely be some change to the module graph as it is just a prototype and 
we may need to easily update the module assignment before we do the 
source restructuring.

Thanks
Mandy