Question ad #AwkwardStrongEncapsulation (Re: Moving the changes in jake to jdk9/dev

[Alan Bateman]

On 14/12/2016 14:30, Jochen Theodorou wrote:

> :
>
> I don't intend to get access to hidden API after all... just exported.
If you only interested in accessing the types and members that you have 
access to in these exported packages then you don't need setAccessible 
of course. We have seen a few cases, not many, where code uses 
setAccessible for performance reasons but I don't know if this is what 
you are thinking about here.


> Which leaves us with: you want this change and I am unhappy with it. I 
> don't see a technical reason for the limit.
Strong encapsulation has always been a goal of this project. If you let 
setAccessible be used to suppress access and get at any member of any 
type then it makes a mockery of that. The initial attempt at a 
compromise in 2015 was to have it fail when attempting to break into any 
member of any type in non-exported packages. That is what has been in 
JDK 9 for some time. The problem with this compromise is that it makes 
it impossible to encapsulate the internal implementation that is in 
exported package - if you read the JSR issue then you'll see the example 
of code breaking into java.lang.invoke.MethodHandles.Lookup to get at 
its private constructor and using that to create full power lookups with 
a lookup classes in non-exported packages. You'll also see the 
unworkable concern that module authors will be forced to move all their 
internals to non-exported packages. This is what 
#AwkwardStrongEncapsulation is about.  Hopefully it's a bit clearer now.

-Alan