#CompileTimeDependencies and module resolution

Stephen Colebourne scolebourne at joda.org
Fri Jan 13 12:01:45 UTC 2017

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

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.


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

More information about the jigsaw-dev mailing list