----- Mail original -----
> De: "David M. Lloyd" <david.ll...@redhat.com>
> À: "Sander Mak" <sander....@luminis.eu>, "jigsaw-dev"
> Envoyé: Vendredi 13 Janvier 2017 15:23:56
> Objet: Re: #CompileTimeDependencies and module resolution
> On 01/13/2017 06:48 AM, Sander Mak wrote:
>>> 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
>> 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
>> ever use the matrix multiplication lib A directly in my application, but I
>> 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
>> without A just as well. Obviously Lib needs to guard for this situation, as
> This is the intuitive behavior I also expect of an optional dependency.
> The problem however is that a static dependency isn't an optional
> dependency; it's a compile-time-only dependency, which is not exactly
> the same thing.
> We (Jigsaw) don't have a concept of an optional dependency (i.e. one
> that is eagerly used if present but does not cause an error if absent)
> at all. Maybe we should though, as experience has shown that this is a
> useful operating mode.
You can implement it at runtime if you control the Layer, either by removing
the requires directive or by synthetising a fake module descriptor
corresponding to the dependency.
>> 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
>> make the example I described above a bit awkward, but I don't have any data
>> which use case is more prevalent.
>> Thanks for the insights!
> - DML