Services and Bindings - expected usage scenarios

[mark.reinhold at oracle.com]

2016/11/29 9:30:29 -0800, vitaliy.pisarev at hpe.com:
> Thank you mark, this goes far to answer my question. 
> 
> I do want to ask you 3 follow-up questions:
> 
> ...
> 
> By promoting the SL pattern, aren’t you effectively taking a stand in
> this debate? An SL proponent might say: "Look! The Java architects
> actually made it part of the language! so it must be superior to DI"
> But of course the validity (or-invalidity) of this sentence comes from
> your intent, not from the fact.

I can equally well imagine a DI proponent saying, "Look!  The Java EE
architects made CDI part of the EE platform, so it must be superior
to SL and those Java SE architects must be idiots!".

I take no position on whether DI is inherently superior to SL, or
vice-versa.  Each approach has its strengths and weaknesses.  I do
agree with Fowler [1]:

  The choice between Service Locator and Dependency Injection
  is less important than the principle of separating service
  configuration from the use of services within an application.

The SE Platform has ServiceLoader rather than a built-in DI mechanism
because the former is more primitive and imposes less overhead, while
the latter can be built on top of the former.  (I don't really know,
nor care, whether java.util.ServiceLoader is officially an instance
of the Service Locator pattern.)

> Also- what would you say to an application that does use a DI
> framework? would you say that using an SL in this constellation is
> inferior or would you justify cases where DI and SL can be applied in
> conjunction?

I'm no Pattern Philosopher, but in the abstract I'd say that using
both DI and SL in the same component (i.e., module) is probably a
code smell, while using both in a large, multi-component application
is probably unavoidable and nothing to worry about.

> Finally, it seems to me that the gaols of Jigsaw as stated in the JSR
> are fully met even without the service provider clause in the module
> declaration.  Seeing that each feature in the language is astoundingly
> expensive, you must have had very strong incentive to push for this
> direction. I wonder what was it that drove you to include this?

In a modular system, a specific implementation of a service can be
composed of multiple modules.  Provisioning a service can thus induce
the resolution of additional modules, which can in turn induce the
provisioning of additional services.  Module resolution and service
provisioning are, in other words, recursively intertwined, hence it's
not just appropriate but necessary for the module system to take
services into account.

- Mark


[1] http://martinfowler.com/articles/injection.html