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

[Neil Bartlett]

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. 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”> …

Regards,
Neil


> On 16 Nov 2015, at 16:45, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> 
> 
> On 16/11/2015 12:28, Stephen Colebourne wrote:
>> Access to private members of classes by reflection is indeed very,
>> very common. I agree that JDK 9 needs to be cautious around this.
>> 
>> 
> I think this thread is just highlighting the obvious tension between modules with encapsulation vs. serialization and other frameworks that need to break encapsulation. At this time then explicit modules have to opt-in to allow frameworks get access types in those packages. This can be done in the module declaration or at run-time via the API. The alternative is of course the all-powerful command line.
> 
> As regards setAccessible(true) then it would be nice to have it eventually go away in some future release. This would clearly require coming up with solutions to some difficult problems and use-cases.
> 
> -Alan