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.bate...@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