Services and Bindings - expected usage scenarios

[Jochen Theodorou]

I am not of the expert group, but I would like to give a partial answer.

Let us think of a kind of plugin architecture. There is a public 
interface from your framework and there are other modules that are going 
to provide plugins by implementing that interface. Now assume the 
framework will also instantiate the plugin. This is a problem, because 
normally a plugin is an implementation detail and its only public aspect 
is supposed to be the interface it implements. But to create an instance 
of it, you need to execute a constructor, which would then originate in 
private API.

Thus the ServiceLoader API and the module logic and descriptor got 
extended to support this.

bye Jochen

On 29.11.2016 14:13, Pisarev, Vitaliy wrote:
>
> What about the intent behind how are developers supposed to use this tool?
>
> For example, when Optional was introduced in Java 8, it was specified that it is intended to be used as a methods return type. And people should not
> use it as class member or method argument, even though the compiler will not prevent them to.
>
> Here is a language feature that comes with guidelines as to how it is intended to be used.
>
> Can you tell me how the expert group envisions usage of the ServiceLoader in Java 9, with reference to the original question (and any other thing you can add with regard to this).
>
> -----Original Message-----
> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
> Sent: יום ג 29 נובמבר 2016 14:06
> To: Pisarev, Vitaliy <vitaliy.pisarev at hpe.com>; jigsaw-dev at openjdk.java.net
> Subject: Re: Services and Bindings - expected usage scenarios
>
> On 29/11/2016 11:35, Pisarev, Vitaliy wrote:
>
>> Another best practices question.
>>
>> I am aware that the ServiceLoader API is not new to Java. What's new
>> in Java 9 is that is has been put forward to the front of the stage and it is now very easy for a service provider to register a service.
>>
>> The thing is that up until now, the ServiceLoader was a relatively low level component, primarily used by infrastructure components that loaded plugins that implemented various java specs.
>> It is no surprise than that the ServiceLoader is something that very few ever heard of.
>>
>> Is it the intent of project Jigsaw that the service loader becomes a central and ubiquitous mechanism in the day to day work of plain old java developers?
>> As far as I am concerned, it is a very useful tool even when I do not
>> have a plugin architecture and just want a module to expose a certain service via an interface without having to jump throw hooks in order to provide the consumer a way to instantiate it..
>>
>> Which leads me to the next question: is the returned instance a singleton or a prototype?
> Services are a first class part of the module system but are a somewhat advanced topic. The ServiceLoader API is part of the story but arguably just a small aspect when compared to the architectural and design issues involved in moving to services, loose coupling, and improved SoC.
>
> Provider factories can implement singletons where needed, the details are in the javadoc [1].
>
> -Alan
>
> [1] http://download.java.net/java/jigsaw/docs/api/index.html
>