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

[Bryan Atsatt]

Alex Buckley wrote:
> Bryan Atsatt wrote:
>>> 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?
>
> 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.
>
>>>> 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 under that.
>
> Yes. I should have said that javac's regular enforcement does make 
> this expectation reasonable.
>
>> 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"?
>
> Oh, then you're on slide 3. Just set SourcePath/ClassPath as today and 
> make sure module-info is in the root. The limitation is that you can't 
> compile multiple modules in a single javac invocation. This is 
> basically slides 6 and 7. To overcome that limitation, javac would 
> have to find the right module-info on the SourcePath/ClassPath by 
> either having module name in source or realizing which SourcePath 
> entry (src/classes1 v. src/classes2) encloses the file being compiled. 
> javac would also have to redefine -d to allow multiple output 
> directories, and slide 7 shows why that's undesirable.
Ah, I interpreted the slides as a progression towards a solution; as 
long as javac will also look in SourcePath/ClassPath for module-info, 
this case is covered.
>
> Alex
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>