[jsr294-modularity-eg] 294 EG conf call, 2009-04-08
bryan.atsatt at oracle.com
Mon Apr 13 21:39:26 EDT 2009
Alex Buckley wrote:
> Bryan Atsatt wrote:
>> In the ModulePath idea from , 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:
>> 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.
Then doesn't it follow that the version number should be "required" in
the directory name as well?
>> 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.
Right, so the compiler can simply check all of the -modulepath entries
for a child directory called "com.bar.app", then expect module-info
What if a user really wants to keep their existing source directory
structure, *and* use module-info? More compiler options (e.g. pointing
directly to module-info files), or "sorry"?
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
jsr294-modularity-eg mailing list
jsr294-modularity-eg at cs.oswego.edu
More information about the jsr294-modularity-observer