#CompileTimeDependencies and module resolution

[Sander Mak]

> 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." [1]

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.


Sander

[1] http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-June/000306.html