> The standard use case for the feature is for libraries with optional
That is indeed the use case I was thinking of.
> The --add-modules flag is only relevant when using the command line to
> turn setup #1 into setup #2, something which should be rare.
Interesting, so what you're saying is if an application wants the optional
behaviour of Lib through A, the application module itself (or any of its
modules) has to declare a non-optional dependency in its descriptor on module
A. Even though, technically, this application module doesn't have any direct
relation at all with A. If you do that, the application can freely use types
exported from A. Which is not always what you want (in most cases even, I'd
say). For example, Lib would be a machine learning library that the application
uses and A would be a super-fast matrix multiplication library (possibly with
native code not available on all platforms, so it has to be optional). I won't
ever use the matrix multiplication lib A directly in my application, but I want
it to be used by Lib for increased performance.
What I was expecting, is that the mere presence of A on the module path would
cause it to be resolved when Lib is resolved, without needing a non-static
requires or --add-modules. Conversely, if A isn't there, Lib would get resolved
without A just as well. Obviously Lib needs to guard for this situation, as you
Alternatively, you can view optional dependency usage more like 'if the
application already uses A, then Lib should also use A as well' in which case
your suggested setup and the current implementation make total sense. This does
make the example I described above a bit awkward, but I don't have any data on
which use case is more prevalent.
Thanks for the insights!