> On Dec 3, 2015, at 2:49 PM, mark.reinh...@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
