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.
Cheers, Paul On Mon, Nov 16, 2015 at 10:45 AM, Alan Bateman <alan.bate...@oracle.com> wrote: > > > 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. > > -Alan >
