More flexibility in providing services from modules?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

More flexibility in providing services from modules?

Tom De Wolf
The current ServiceLoader mechanism and Java Modules have a limited set of
options to provide an instance for a service from a module. Or you use the
constructor, or you use a static 'provider' method.

When interacting with frameworks like Spring this does not give a lot of
flexibility. I described the problem statement and some ideas which could
be considered for evolving the services support in the module system in
this blog post:

https://devcreativity.wordpress.com/2019/03/02/java-modules-wish-list-provide-services-using-lambda-functions-and-more/


I would appreciate if some of the oracle contributors that worked on the
module system could read the post and provide me and the community with
some feedback if such a change could be a good idea?

Thanks in advance

Tom
Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in providing services from modules?

Alex Buckley
Hi Tom,

Nice to see thoughts about modular services.

FYI Jigsaw's goals in this area were quite limited
(http://openjdk.java.net/projects/jigsaw/spec/reqs/#services) and the
static provider method was a relatively late add-on
(http://openjdk.java.net/projects/jigsaw/spec/issues/#services).

I agree that a static provider method offers a basic level of
indirection (e.g. multiple `provides` directives can employ the same one
if its return type implements multiple services) but it doesn't add much
in the way of abstraction (e.g. over the desired service). This isn't
the only place where ServiceLoader suffers from a lack of abstraction:
you can't parameterize services because there's no way to request an
implementation of a parameterized service (i.e. you can't say
`ServiceLoader.load(ServiceA<Foo>.class)`).

Frankly, we are not likely to revisit any of these limitations in the
near future, but I think that ServiceLoader will always be a handy
built-in option for limited use cases.

Alex

On 3/2/2019 9:19 AM, Tom De Wolf wrote:

> The current ServiceLoader mechanism and Java Modules have a limited set of
> options to provide an instance for a service from a module. Or you use the
> constructor, or you use a static 'provider' method.
>
> When interacting with frameworks like Spring this does not give a lot of
> flexibility. I described the problem statement and some ideas which could
> be considered for evolving the services support in the module system in
> this blog post:
>
> https://devcreativity.wordpress.com/2019/03/02/java-modules-wish-list-provide-services-using-lambda-functions-and-more/
>
>
> I would appreciate if some of the oracle contributors that worked on the
> module system could read the post and provide me and the community with
> some feedback if such a change could be a good idea?
>
> Thanks in advance
>
> Tom
>
Reply | Threaded
Open this post in threaded view
|

Re: More flexibility in providing services from modules?

Tom De Wolf
Hi Alex,

1 of the smaller suggestions in my blogpost (
https://devcreativity.wordpress.com/2019/03/02/java-modules-wish-list-provide-services-using-lambda-functions-and-more/)
was
to pass in the class of the expected service type as a parameter into the
provider method if the signature is defined with a Class as single
parameter. This little extension of the convention would allow already a
lot more flexibility. Would it be possible to consider it?

Thanks,

Tom
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - - - - -
Op ma 4 mrt. 2019 om 21:27 schreef Alex Buckley <[hidden email]>:

> Hi Tom,
>
> Nice to see thoughts about modular services.
>
> FYI Jigsaw's goals in this area were quite limited
> (http://openjdk.java.net/projects/jigsaw/spec/reqs/#services) and the
> static provider method was a relatively late add-on
> (http://openjdk.java.net/projects/jigsaw/spec/issues/#services).
>
> I agree that a static provider method offers a basic level of
> indirection (e.g. multiple `provides` directives can employ the same one
> if its return type implements multiple services) but it doesn't add much
> in the way of abstraction (e.g. over the desired service). This isn't
> the only place where ServiceLoader suffers from a lack of abstraction:
> you can't parameterize services because there's no way to request an
> implementation of a parameterized service (i.e. you can't say
> `ServiceLoader.load(ServiceA<Foo>.class)`).
>
> Frankly, we are not likely to revisit any of these limitations in the
> near future, but I think that ServiceLoader will always be a handy
> built-in option for limited use cases.
>
> Alex
>
> On 3/2/2019 9:19 AM, Tom De Wolf wrote:
> > The current ServiceLoader mechanism and Java Modules have a limited set
> of
> > options to provide an instance for a service from a module. Or you use
> the
> > constructor, or you use a static 'provider' method.
> >
> > When interacting with frameworks like Spring this does not give a lot of
> > flexibility. I described the problem statement and some ideas which could
> > be considered for evolving the services support in the module system in
> > this blog post:
> >
> >
> https://devcreativity.wordpress.com/2019/03/02/java-modules-wish-list-provide-services-using-lambda-functions-and-more/
> >
> >
> > I would appreciate if some of the oracle contributors that worked on the
> > module system could read the post and provide me and the community with
> > some feedback if such a change could be a good idea?
> >
> > Thanks in advance
> >
> > Tom
> >
>