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

[Alan Bateman]

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.