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

[Alan Snyder]

> On Dec 3, 2015, at 2:49 PM, mark.reinhold at oracle.com wrote:
> 
>> I would be happier with a solution that documents specific
>> penetrations of encapsulation in a way that can be interrogated by a
>> tool. Then application developers can choose whether to run the tool,
>> rather than getting random run time access errors or buggy behavior
>> when the penetration is rejected.
> 
> Something like that might work for simple static references to internal
> APIs, such as your workaround scenario.  It's infeasible, however, for
> other use cases in which encapsulation must be broken in a more dynamic
> fashion, e.g., frameworks that use reflection to inspect the internals
> of classes in modules not known when the framework is compiled.

There is no reason to believe that single mechanism will solve all use cases.

However, if having a single mechanism is important, then it sounds like removing the restrictions on reflection would be a good choice.

  Alan