[jsr294-modularity-eg] 294 EG conf call, 2009-04-08

[Alex Buckley]

Bryan Atsatt wrote:
> All of which implies that javac will have to search all (immediate) 
> child directories under ModuleSourcePath for module-info files. And each 
> such directory in which a module-info file is found becomes a module 
> source root.
> 
> Does this also imply that immediate child directories without a 
> module-info file are ignored?
> 
>    src/modules/f/com/foo/HelloWorld.java
>    src/modules/f/module-info.java
>    src/modules/b/Bar.java          // Ignored (not a module member)??

In as much as b/Bar.java won't be compiled automatically, yes, it's ignored.

Don't forget ModuleSourcePath may have entries other than src/modules, 
such as build/gensrc, where module-info-toting directories live.

> Given that the compiler must search for module-info file(s) under 
> ModuleSourcePath, it also seems reasonable to support one directly under 
> the ModuleSourcePath, for symmetry in the simple case (exactly as it 
> would be found using -sourcepath):
> 
>    src/com/foo/HelloWorld.java
>    src/module-info.java

So you're saying that when ModuleSourcePath=src/modules, allow:

src/modules/mymod/com/foo/HelloWorld.java
            /module-info.java  "module mymod {..}"

WITHOUT src/modules/mymod/module-info.java ?

Problem is, -d notices that ModuleSourcePath is set and assumes an 
output directory structure that mirrors the input directory structure. 
Thus module-info.class for mymod is emitted as 
$-dPath/mymod/module-info.class and input:output isomorphism (which 
tools love) is lost.

If you want to compile without changing the directory hierarchy, just 
use SourcePath/ClassPath. The one-module-at-once implication isn't a 
limitation at all, since the layout above only supports only version too.

Alex
_______________________________________________
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg