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

[Ali Ebrahimi]

Hi,
Currently only code inside java.base module can add (qualified)
exports programmatically.



On Wed, Nov 18, 2015 at 12:47 PM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
> 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.
>
> -Alan
>



-- 

Best Regards,
Ali Ebrahimi