Services and Bindings - expected usage scenarios

[Pisarev, Vitaliy]

Thank you mark, this goes far to answer my question. 

I do want to ask you 3 follow-up questions:

You mentioned that an Application that does not use DI (rare sight nowadays) is definitely encouraged to use ServiceLoader 
for achieving low coupling between modules. But ServiceLoader is effectively an implementation of the Service Locator pattern, a pattern that is usually counter to DI. 
There is a whole lot of debate between the DI camp and the SL camp online (each claiming the other is an anti-pattern), and it seems that DI is winning. 

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.

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?

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? 


-----Original Message-----
From: mark.reinhold at oracle.com [mailto:mark.reinhold at oracle.com] 
Sent: יום ג 29 נובמבר 2016 18:10
To: Pisarev, Vitaliy <vitaliy.pisarev at hpe.com>
Cc: jigsaw-dev at openjdk.java.net
Subject: Re: Services and Bindings - expected usage scenarios

2016/11/29 6:54:35 -0800, vitaliy.pisarev at hpe.com:
> ...
> 
> I am looking at the great features in Java 9 and I know that we are 
> going to "jump" on the new module system with all the encapsulation it 
> gives us.  But I and my fellow Architects are very unsure what to 
> think of the ServiceLoader.
> 
> Some of the push-back I get is that it is a "low level component"
> meant for authors of infrastructure libraries.  Others tell me to 
> forget about using the ServiceLoader as a Service Locator and stick to 
> good old Spring. Yet others tell me that the Java Expert group has 
> actually taken a stand in the "Dependency Injection vs ServiceLocator"
> debate, by streamlining the ServiceLocator pattern instead of going 
> with JDK level Dependency Injection.
> 
> Discussions are heated, and I figured to go to the source instead of 
> deducing our own conclusions with so little information.

I agree largely with what Rémi wrote nearby, though I'd put it a bit differently.

The Java SE Platform does not, itself, do Dependency Injection, and it almost certainly never will.  Not every application needs DI.

Java SE should, however, provide the primitives needed by all types of applications, including those that use DI frameworks built on top of it.
SE modules can therefore identify service users and providers, and the existing SE ServiceLoader API has been enhanced accordingly.

If you're writing an application without a DI framework but have a need for loose coupling between modules then you should use the ServiceLoader API directly.  If you're using a DI framework then we hope that, over time, DI frameworks will leverage the ServiceLoader API as appropriate.
That change is, however, not something that those of us who work on the module system can make ourselves; we can only enable and encourage it.

- Mark