----- Mail original ----- > De: "David M. Lloyd" <david.ll...@redhat.com> > À: "Sander Mak" <sander....@luminis.eu>, "jigsaw-dev" > <jigsaw-dev@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
