#CompileTimeDependencies and module resolution

[Remi Forax]

----- Mail original -----
> De: "David M. Lloyd" <david.lloyd at redhat.com>
> À: "Sander Mak" <sander.mak at luminis.eu>, "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> 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
>>> 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
>> said.
> 
> 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 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!
>>
>>
>> Sander
>>
> 
> --
> - DML

Rémi