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 <[email protected]> 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
