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

[Alan Bateman]

On 14/12/2016 09:56, David Holmes wrote:

>
> Sorry I don't follow. Calling setAccessible(true), logically does 
> nothing except set a flag that controls whether reflective use of the 
> member will need to pass an access check -it doesn't (or shouldn't) 
> perform the access check!
Best to read the javadoc as this changed to align with modules. When 
reading the javadoc then keep in mind that the JDK modules do not open 
their packages for deep reflection.

> The actual use then has the full access check. Due to the added 
> complication of module encapsulation we can't simply skip the access 
> check if setAccessible is true, because we also need to see if the 
> target module is "open" in the right way.
If setAccessible(true) succeeds then it means access checks are 
suppressed when using that AccessibleObject is used. There are no 
changes here. Having setAccessible(true) succeed but still do an access 
check when using the AccessibleObject would be too significant a change 
in behavior.


>
> If the current implementation is trying to cache the result of the 
> accessibility check at setAccessible time then that would seem an 
> invalid attempt at optimisation. java.lang.reflect objects are not, 
> AFAIK, intended to be capabilities the way MethodHandles are.
I don't see an issue here as it is not used when the accessible flag has 
been set with setAccessible(true).

>
> BTW in this discussion when setAccessible says that it is "suppressing 
> default Java language access control checks" are the module related 
> checks considered "language access control checks" or are they 
> considered something outside the language?
The former.

-Alan