A way to opt out of access restrictions on non-exported members.

[Neil Bartlett]

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.Bateman at 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.