A way to opt out of access restrictions on non-exported members.
ali.ebrahimi1781 at gmail.com
Wed Nov 18 10:04:53 UTC 2015
Currently only code inside java.base module can add (qualified)
On Wed, Nov 18, 2015 at 12:47 PM, Alan Bateman <Alan.Bateman at oracle.com>
> On 18/11/2015 01:18, Paul Benedict wrote:
>> I don't see how this approach could ever work in an EE container. An
>> existing module can't guess who needs to reach inside to perform dependency
>> injection, annotation or class scanning. Can't there be some concept of a
>> "trusted" module (signed?) that gives it superuser access to any other
>> module? Obviously an EE container would fit this description.
>> The EE container case might not be too bad as the EE container creates
> the configuration and so could arrange additional qualified exports when
> not using services. Details TBD, it might be that the container injects a
> helper into the application configuration, maybe it wraps the entry point
> so that code to export the otherwise internal packages to the
> framework/container. Modules are a fundamental change and it's important
> that we get it right. To that end, it's important to have a number of
> frameworks/containers working with us and helping to understand and work
> through the migration issues.
More information about the jigsaw-dev