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

Alex Buckley Alex.Buckley at Sun.COM
Mon Apr 13 20:41:37 EDT 2009


Bryan Atsatt wrote:
> In the ModulePath idea from [2], the module name (and an optional 
> version) are encoded as a directory name, which is assumed to be a child 
> of a -modulepath directory reference. From page 10:
> 
>     src/modules/com.foo.app/com/foo/HelloWorld.java
>                            /module-info.java
>                /com.bar.app/com/bar/Baz.java
>                            /module-info.java
> 
> where "src/modules" is the -modulepath reference (apologies if the 
> formatting didn't make it through ;^).
> 
> Are you assuming that the child directory name is required to match the 
> name (and version) declared within the enclosed module-info.java file? 
> Or would this simply be a useful convention?

"required" is a strong word. The JLS won't mention any of this except by 
way of non-normative example.

javac will enforce a match between the immediate child of ModulePath and 
its enclosed module-info.java/class. It is checked when compiling 
module-info.java and when reading module-info.class. It extends the 
current practice of enforcing a match between the location at which a 
class is found on the SourcePath/ClassPath and the fully-qualified name 
of that class.

> IOW, is there some lookup logic assumed here, allowing the compiler to 
> search for the module-info for "com.bar.app" without cracking open the 
> module-info files?

In all cases I can think of, if the compiler needs the module-info for 
com.bar.app, then it needs to open com.bar.app/module-info. The check is 
somewhat auxiliary.

Alex


More information about the jsr294-modularity-eg mailing list