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

[mark.reinhold at oracle.com]

2015/12/1 3:29 -0800, javalists at cbfiddle.com:
>> On Dec 1, 2015, at 2:13 PM, mark.reinhold at oracle.com wrote:
>> Yes.  The users of your library are, knowingly or (usually) not, in an
>> inherently dangerous position.  Their own libraries or applications now
>> depend upon undocumented and unsupported internals of the JDK, which are
>> subject to change at any time and for any reason.  If they have to use
>> a command-line flag to enable such hacks then they are more likely to
>> recognize the danger, so they can judge the risk and plan accordingly.
> 
> That sounds good in theory, but in practice it may be judged an
> annoyance with little or no actual benefit.
> 
> In the case of a workaround, what is likely to happen if the JDK
> changes in an incompatible way is that the workaround fails, leaving
> the application in the same situation it would be without the
> workaround, i.e. with buggy behavior.
> 
> Also, there are plenty of ways that code can depend on JDK
> implementation details without using private APIs, and there is no
> protection from that.

Well sure, but that's not a reason to not provide protection from other
kinds of implementation details when that's possible.

> I think your comment about JDK internals being subject to change at
> any time is overstated. The application developer will only be
> affected when they upgrade to a new JDK version, not at random times,
> and upgrading to a new JDK version merits extensive retesting.

Yet one of the reasons that it merits extensive retesting is precisely
because so many libraries depend upon JDK-internal APIs.

>> I do think it's worth exploring alternative ways to break encapsulation
>> which are more compact, more narrowly scoped, and yet give modules that
>> really need to do that some additional flexibility.  One idea we've
>> considered is a command-line option to grant a module the power to break
>> whatever encapsulation boundaries it needs to, via the API.  That way a
>> user would just need to grant your module this power on the command line
>> rather than be concerned in any way with the specific modules/packages
>> your code needs to break into, and also you, over time, can update your
>> library to change or minimize the amount of encapsulation that it
>> breaks.
> 
> 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.

- Mark