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

[Alan Snyder]

> On Dec 1, 2015, at 2:13 PM, mark.reinhold at oracle.com wrote:
> 
> Is it the position of the jigsaw team that I should not do this?
> 
> If you must do this then you should be aware that you're doing it and,
> more importantly, users of your code should be aware that you're doing
> it on their behalf.
> 

Fair enough. I would be happier with something less obtrusive, though.


>> Is it the position of the jigsaw team that it is acceptable for
>> someone in my position to somehow inform and convince every
>> application developer who knowingly or unknowingly uses a library to
>> change the command line arguments in their build configuration so that
>> this workaround will run? (And later, presumably, get them all to
>> remove the command line argument when the workaround is no longer
>> needed?)
> 
> 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.

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.


> 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.

One idea - requiring an annotation at the point in the source code where an other inaccessible symbol is used, and collecting that information in some accessible form.

Another idea - having a declaration in the Manifest of the library JAR stating the extra privileges it needs.

  Alan