[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