Thanks Alan,
So you’re saying that ServiceLoader is permitted to have “super powers” to
punch through encapsulation, but other libraries are not. This is disappointing
— ServiceLoader is extremely limited in functionality, and is no match for any
of the widely used DI frameworks like Spring, Guice, CDI etc. Why should this
library be blessed above all others?
Neil
> On 16 Nov 2015, at 18:57, Alan Bateman <alan.bate...@oracle.com> wrote:
>
> On 16/11/2015 17:48, Neil Bartlett wrote:
>> Alan,
>>
>> In your consideration does the following declaration break encapsulation of
>> a module, assuming that package “org.example.impl” is not exported?
>>
>> module foo {
>> provides org.example.api.ServiceInterface with
>> org.example.impl.ServiceImpl;
>> }
>>
>> This appears to allow the ServiceLoader to punch through encapsulation and
>> obtain instances of a non-exported type.
> Sure, but this just part of the support for services. In this example then
> the service provider is fully encapsulated. The consumer of the service can't
> access ServiceImpl, it instead accesses it via ServiceInterface (assuming of
> course that the consumer reads the module with ServiceInterface and
> org.example.api is exported to the consumer).
>
>> How does this differ from a declaration that one might see in a Dependency
>> Injection framework such as Spring? I.e. something like:
>>
>> <bean class=“org.example.impl.ServiceImpl”> …
>>
> There isn't way to give Spring super powers so this needs foo to export
> org.example.impl to Spring.
>
> -Alan.
