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

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!


Reply via email to