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

[Bryan Atsatt]

Alex Buckley wrote:
> Bryan Atsatt wrote:
>>>> Then doesn't it follow that the version number should be "required" 
>>>> in the directory name as well?
>>>
>>> When multiple modules of the same name are on the filesystem at 
>>> once, sure. When only one version of a module is present, I'm not 
>>> sure requiring a version literal is helpful. (Maybe a version isn't 
>>> just a number :-) Certainly it should not be mandatory to give a 
>>> version when declaring a module in the language.
>>>
>>> That said, let Jon and I discuss this some more.
>
> On reflection, we think the child of ModuleSourcePath is not a name 
> that javac can take any meaning from.
>
> First, the artifact in which a module is packaged may have a friendly 
> name (inc. a version) that differs from the packaged module's name. It 
> would be nice to unjar antlr-4.0-src.jar as follows and start compiling:
>
> src/modules/antlr-4.0-src/org/antlr/...
>                          /module-info "module antlr.main @ 4.0 {..}"
>
> Second, ModuleSourcePath is likely to contain just one version of each 
> module. It's not worth javac mandating versions in directory names for 
> the edge case of compiling multiple versions of a module at once 
> (directly or due to transitive dependencies).
>
> Third, if a module system supports aliased module names, then just 
> checking the directory name is insufficient; javac has to open up each 
> module-info.java/class. (Even for modularized classes under 
> ModulePath, which DO deserve being in directories that contain 
> versions. Different rules for different paths is no fun; we choose to 
> not enforce anywhere.)
>
> Overall, it's the existence of the child under ModuleSourcePath that's 
> important, not the string name of the child. In common cases, you'll 
> see equivalence between the child's name and the contained module 
> name, but javac won't guarantee it.
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)??

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

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