Module declarations

[mark.reinhold at oracle.com]

(splitting your initial reply into separate threads)

2015/9/9 1:48 -0700, david.lloyd at redhat.com:
> On 09/09/2015 11:51 AM, mark.reinhold at oracle.com wrote:
>> To get the discussion started I suggest we focus first on the high-level
>> aspects of the design covered in "The State of the Module System" [1].
>> 
>> [1] http://openjdk.java.net/projects/jigsaw/spec/sotms/
> 
> 1) The first thing that jumps out at me (again) is making module 
> declarations be a binary construct produced by the actual programming 
> language.  It strikes me as arbitrary as well as redundant (given 
> there's a programmatic API to build descriptors, they could simply be 
> parsed from text nearly as well, and a lot more nicely from the user's 
> perspective).  As pointed out in the document, it is already expected 
> that additional tooling would synthesize this file at build time, 
> further decreasing the value of such an idea.  The module class file 
> just seems pointless to me.

One of our requirements is fidelity across all phases.  To achieve this,
javac (or whatever Java compiler you use) must be able to locate and
interpret descriptions of modules.  If modules are not described by
language constructs that are compiled into class files, then how and
where would you suggest that a compiler find such information?

(The statement that "build tools, in particular, can synthesize module
 declarations from information already available in project descriptions"
 in the SotMS document is, I see, overly terse.  A tool could suggest an
 initial module declaration with `requires` clauses derived from a
 pom.xml file, or equivalent, but it'd be up to the developer to specify
 the rest.  I'll fix this in the next version.)

- Mark