Remi, good point on the Class.forName. I guess that the main difference is that Class.forName requires the concrete type - it is up to the consumer to specify (and know) the serviceprovider, whereas the SL resolves a request for an interface and the consumer remains oblivious of the identity of the provider. In this sense I am referring to the ServiceLoader as a ServiceLocator.
-----Original Message----- From: Remi Forax [mailto:fo...@univ-mlv.fr] Sent: יום ג 29 נובמבר 2016 21:38 To: Pisarev, Vitaliy <vitaliy.pisa...@hpe.com> Cc: jigsaw-dev@openjdk.java.net Subject: Re: Services and Bindings - expected usage scenarios DI and SL are two user APIs of a glorified Map between a type and a factory of the corresponding runtime type. DI uses a meta-protocol based on annotations (or javadoc comments :) ) while SL uses a more classical API. The ServiceLoader API is not a Service Locator, the configuration is exposed and known statically. With the right jlink plugin you can even never call the ServiceLoader API at runtime. With your definition, is the Classloader API/Class.forName is a Service Locator ? and until we can access to invokedynamic in Java which is the only true way to implement meta-protocols in Java, all DIs/SLs will suck. regards, Rémi ----- Mail original ----- > De: "Vitaliy Pisarev" <vitaliy.pisa...@hpe.com> > À: "mark reinhold" <mark.reinh...@oracle.com> > Cc: jigsaw-dev@openjdk.java.net > Envoyé: Mardi 29 Novembre 2016 18:30:29 > Objet: RE: Services and Bindings - expected usage scenarios > 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.reinh...@oracle.com [mailto:mark.reinh...@oracle.com] > Sent: יום ג 29 נובמבר 2016 18:10 > To: Pisarev, Vitaliy <vitaliy.pisa...@hpe.com> > Cc: jigsaw-dev@openjdk.java.net > Subject: Re: Services and Bindings - expected usage scenarios > > 2016/11/29 6:54:35 -0800, vitaliy.pisa...@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
