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

[Alex Buckley]

Hi Roman,

I considered having "deep" module-info files as you suggest:

src/com/acme/foo/m1/A.java
                    /module-info.java  "module com.acme.foo.m1;"
                 /m2/B.java
                    /module-info.java  "module com.acme.foo.m2;"

Finding module-info is easy when each package becomes a module, but 
that's not the common case. The common case is multiple packages joining 
a module. If there's no module name in A.java or B.java, then how does 
javac find the m2 module:

src/com/acme/foo/m1/A.java
                 /m2/B.java
                    /module-info.java  "module com.acme.foo.m2;"

A non-answer is "module membership in A.java and B.java", since the EG 
has clearly expressed its opposition to that. Another non-answer is "a 
command-line switch", since that means only one module at a time can be 
compiled. (I had offered a switch previously but there is no need when 
module-info files are "shallow", i.e. directly under sourcepath or in a 
modular structure on modulepath.)

Here is a similar example where javac has to walk up the hierarchy 
looking for a module-info to contain C:

src/com/acme/foo/m1/m10/m100/C.java
                        /module-info.java  "module com.acme.foo.m1.m10;"

Peter had proposed something like this to the EG but it did not gain 
much favor at the face-to-face meeting in March.

As for module names, we don't know how they will be structured. Linux 
distros cope quite well with short names (+versions) for rpm/deb files. 
Even if module names follow the reverse-domain-name convention, they may 
not overlap with package names:

src/com/acme/foo/m1/A.java
             /bar/m2/B.java
             /foobarapp/module-info  "module com.acme.foobarapp;"

Again, without module names in source, how does javac find the app1 
module when compiling A and B? Language modules do not HAVE to be used 
like deployment modules, but the clear sense of the EG is that language 
modules should support deployment modules.

Alex

Roman Elizarov wrote:
> Hello Jonathan!
> 
> Thanks for details.
> 
> My basic problem with suggested approach is that it equates language
> modules and deployment modules. The compilation model basically
> requires me to package and deploy each language module separately (in
> its own .jar or .jam). It does not really support the notion of
> language modules that could be widely used to control the
> architectural aspects of application (that is to control
> dependencies). It makes "fine grained" modularity prohibitively
> expensive, because it requires you to have an unwidely deployment and
> source structure. I don't want to end scanning through a plain list of
> hundreds of module subdirectories in my "modules" directory. Working
> with this structure without an IDE will become just a pain. I am not
> against IDEs, but the source tree (and source code) should be easy to
> scan though even without one, and the language design should not have
> a goal of increasing IDE usage and/or sales.
> 
> Moreover, many existing projects already have <module>/src/java/** or
> src/java/<module>/** structure, or similar, but their <module> name is
> completely unstructured, hence extremely prone to name collisions. I
> fear that with out-of-the box support of those structures from javac,
> these projects will be inclined to keep their existing module names
> instead of using package-like structured names.
> 
> Even though I an not in favor of equating packages and modules, I
> consider it extremely important to nudge developers into using module
> names that are equal to their package names. That is, make it easy to
> define a module if and only if its name is also equal to the package
> name and make all the other cases harder. Your current approach seems
> to be completely opposite. For many projects it will be easier to use
> their existing short and potentially colliding names as their module
> names, hence we will be bound to have a "module hell".
> 
> Sincerely,
> Roman Elizarov
> 
> On Sunday, April 19, 2009 12:55:09 AM you wrote:
> 
> JG> Roman,
> 
> JG> See the announcement here:
> JG>        
> JG> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2009-April/000077.html
> JG> and the rationale and presentation here:
> JG>        
> JG> http://openjdk.java.net/projects/jigsaw/doc/ModulesAndJavac.pdf
> 
> JG> -- Jon
> 
> JG> On Apr 18, 2009, at 12:29 PM, Roman Elizarov wrote:
> 
>>> Hello Alex!
>>>
>>> I've missed the moment in time when the decision was made to host
>>> module-info.java file in the root of classpath and/or in the immediate
>>> subdirectory of modulepath. What is the rationale of that decision?
>>>
>>> Why I have to change the directory structure of my project in order to
>>> get advantage of modules?
>>>
>>> Let us say that I have a following source tree:
>>>
>>> src/com/acme/foo/m1/*.java -- my 1st "module"
>>> src/com/acme/foo/m2/*.java -- my 2nd "module"
>>>
>>> Currently, in my build file, I just compile it all with:
>>>  javac src/**.java -d classes
>>> and create 2 separate jar files -- m1.jar with
>>>  jar cvf m1.jar -C classes com/acme/foo/m1/*.class
>>> and m2.jar with
>>>  jar cvf m1.jar -C classes com/acme/foo/m2/*.class
>>>
>>> Now, I want to define some module metadata for m1 and m2.
>>>
>>> I would like just to add the following two files to my source tree:
>>>
>>> src/com/acme/foo/m1/module-info.java -- meta info for  
>>> com.acme.foo.m1 module
>>> src/com/acme/foo/m2/module-info.java -- meta info for  
>>> com.acme.foo.m2 module
>>>
>>> and use my "legacy" javac command line (making it also automagically
>>> compatible with the all the tools I use like "ant" and everything
>>> else).
>>>
>>> Will I be able to do that or not? From your latest document the answer
>>> seems to be no. I am really puzzled. Why there should not be a simple
>>> solution to this simple use-case?
>>>
>>> Sincerely,
>>> Roman Elizarov
>>>
>>> On Saturday, April 18, 2009 5:27:04 AM you wrote:
>>>
>>> AB> 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).
>>> AB> So that ModuleSourcePath/ModulePath supercede SourcePath/ 
>>> ClassPath even
>>> AB> when only one module's source is in play ?
>>>
>>> AB> We thought about this, and concluded that it's possible to drop
>>> AB> ModuleSourcePath, but not ModulePath. See attached PDF, in  
>>> particular
>>> AB> slide 15.
>>>
>>> AB> Basically, by having only SourcePath and not also  
>>> ModuleSourcePath,
>>> AB> javac needs to infer a key piece of info; the configuration of
>>> AB> -classpath and -modulepath lets it do that. See slide 17.
>>>
>>> AB> Alex
>>>
>>>
> 
>