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

[Peter Kriens]

I hope it is clear that share all these concerns.

Kind regards,

	Peter Kriens

On 19 apr 2009, at 13:18, 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
>>>
>>>
>
>