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

Alex Buckley Alex.Buckley at Sun.COM
Fri Apr 17 21:27:04 EDT 2009


Bryan Atsatt wrote:
>>> 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 ?
> Actually I was suggesting that the Module[Source]Path machinery handle 
> the degenerate case where there is no child "<module-name>" directory at 
> all, and both the package root and module-info are immediately within 
> the named directory (as in my example above, where ModuleSourcePath=src).

So that ModuleSourcePath/ModulePath supercede SourcePath/ClassPath even 
when only one module's source is in play ?

We thought about this, and concluded that it's possible to drop 
ModuleSourcePath, but not ModulePath. See attached PDF, in particular 
slide 15.

Basically, by having only SourcePath and not also ModuleSourcePath, 
javac needs to infer a key piece of info; the configuration of 
-classpath and -modulepath lets it do that. See slide 17.

Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Compiling modules.pdf
Type: application/pdf
Size: 92724 bytes
Desc: not available
URL: <http://cs.oswego.edu/pipermail/jsr294-modularity-eg/attachments/20090417/eefe2db7/attachment-0001.pdf>


More information about the jsr294-modularity-eg mailing list