A way to opt out of access restrictions on non-exported members.
javalists at cbfiddle.com
Thu Dec 3 23:41:42 UTC 2015
> 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.
More information about the jigsaw-dev