A way to opt out of access restrictions on non-exported members.
pbenedict at apache.org
Wed Nov 18 01:18:43 UTC 2015
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.
On Mon, Nov 16, 2015 at 10:45 AM, Alan Bateman <Alan.Bateman at oracle.com>
> 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.
More information about the jigsaw-dev