2015/12/1 3:29 -0800, javali...@cbfiddle.com: >> On Dec 1, 2015, at 2:13 PM, mark.reinh...@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
