#CompileTimeDependencies and module resolution
sander.mak at luminis.eu
Sat Jan 14 20:33:05 UTC 2017
> On 13 Jan 2017, at 14:45, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 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.
> For Stephen's example then it would be better to steer people to using services and avoid the reflection guard that Lib would need to cope with A not being resolved.
I agree, but retro-fitting services onto existing code is not always viable.
The rationale for not eagerly resolving `requires static` dependencies is:
" [...] it could lead to surprising
behavior in which optional dependences silently cause many additional
modules to be resolved." 
To me, this seems to be exactly the same reasoning that caused service providers not to be automatically resolved at link-time (which is fine). However, service providers *are* automatically resolved at run-time. Why is this less confusing than eagerly resolving `requires static` dependencies from the module path at run-time? I honestly don't see the difference here. In fact, `requires static` even names the module that will be resolved. Whereas `uses` indirectly causes (unknown) provider modules to be resolved, which is arguably more confusing.
Eagerly resolving `requires static` dependencies when they're on the module path makes them behave more like optional JARs you put on the classpath currently, without diminishing their value as compile-time-only dependencies for the annotations use-case. Seems like a net win to me.
More information about the jigsaw-dev