#CompileTimeDependencies and module resolution

[Stephen Colebourne]

The standard use case for the feature is for libraries with optional
dependencies:

module Lib { requires static A; requires B; }
module A { ... }
module B { ... }

Given this setup:
 module App1 { requires Lib; }
the module graph should include App1, Lib and B.
Any use of A from Lib must be guarded, as A is not present.

Given this setup:
 module App2 { requires Lib; requires A }
the module graph should include App1, Lib, A and B.
Module A will be visible and read by Lib.

ie. the optional depenedency expresses the concept of "use module A if
it is available, otherwise ignore it"


The --add-modules flag is only relevant when using the command line to
turn setup #1 into setup #2, something which should be rare.

Stephen


On 13 January 2017 at 11:33, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 13/01/2017 11:08, Remi Forax wrote:
>
>> Hi Sander,
>> you're right, it's a bug, --add-modules should not be necessary.
>>
>> Rémi
>
> I don't think there is a bug here. Instead the example that Sander has
> chosen doesn't resolve a module that `requires B`. The "Notes" section in
> #CompileTimeDependences proposal has the rational for this. If the example
> is extended to:
>
> module A { requires static B; requires C; }
> module B { ... }
> module C { requires B; }
>
> then the resulting module graph will have contain at least A, B and C, and A
> will read at least B and C.
>
> -Alan