> On 13 Jan 2017, at 14:45, Alan Bateman <alan.bate...@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
