Modules and build time

[David M. Lloyd]

On 12/09/2015 07:28 PM, mark.reinhold at oracle.com wrote:
> 2015/10/21 4:21 -0700, david.lloyd at redhat.com:
>> I have a problem with the premise that modules should be directly
>> consumable by the build in the same way they are consumed at run time.
>> Building a typical Java artifact today generally entails the Maven
>> approach, which, roughly translated into modularisms, would look
>> something like this:
>>
>> * We build artifacts, not modules
>> * The build consumes (specific versions of) modules for build tasks such
>> as resource processing, descriptor generation, annotation processing, etc.
>> * The build consumes (specific versions of) artifacts for the build
>> class path; these artifacts generally correspond to a minimum version of
>> a module that is expected to be mandatorily or optionally present at run
>> time, but also may correspond only to specific APIs expected to be
>> present at run time
>> * The run time environment may consist of a set of modules that does not
>> have a direct correspondence to the artifacts used for build
>> * The test time environment may consist of a set of modules that does
>> not have a direct correspondence to the artifacts used for build
>>
>> To me there is no sensible way to reconcile these facts against the
>> proposed Jigsaw methodology of having javac reference modules directly.
>>    This would mean that all build artifacts have to be packaged as
>> modules and transported to the user for build, which further means that
>> every user would need to define a complete, build-specific modular
>> environment, ...
>
> I'm not completely sure what you're getting at here, but it's not the
> case that all of the modules needed to run a particular module must be
> present to compile that module.  The compiler only needs to resolve the
> immediate and implied read edges of the module(s) being compiled.  If
> module A requires B, and B requires C, then the compiler can compile A
> without inspecting C.  If B requires public C, however, then the compiler
> must inspect C also, and therefore resolve it.  All of this follows from
> the definitions of readability and implied readability.

Sure, I agree this logic is inescapable.  The question is, what B and 
what C do I build against?  Once a module is built, it is not "forever", 
it is only until a different version of the module is built.  Every time 
I build something, I'm using a different subgraph of an overall module 
universe, and that subgraph extends to all previously built versions of 
each of those things.  At run time I'm using a subgraph of this module 
universe that is very unlikely (past the first version of something) to 
match the build subgraph.

-- 
- DML