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

[David Holmes]

Hi Peter,

On 14/12/2016 5:30 PM, Peter Levart wrote:
> Hi David,
>
> On 12/14/2016 07:17 AM, David Holmes wrote:
>>> But let me explain why .setAccessible(true) can't be allowed for
>>> protected members in general.
>>
>> I'm confused as to what is being argued for/against here.
>
> Rony asked why .setAccessible(true) can't be used for protected members
> even if called from a subclass of the member's declaring class.
>
>> setAccessible(true) simply says to disable access checks when the
>> member is used. At the time of use you have all the necessary
>> information available:
>> - current class
>> - member defining class
>> - receiver class (target class??)
>
> At the time of use (when the member is reflectively accessed), you have
> that information, but that information is not used when the access
> checks have been suppressed by .setAccessible(true). When the
> .setAccessible() is called OTOH, you don't have the target (receiver)
> object, so you can't allow .setAccessible() to succeed for protected
> instance member if you want to respect strong encapsulation as this
> would allow elevation of access privilege. You only allow elevation if
> the member's declaring class is in an open package (or in unnamed module).

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

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?

Cheers,
David
-----

> ...
>>>     /**
>>>      * Verify access to a member, returning {@code false} if no access
>>>      */
>>>     public static boolean verifyMemberAccess(Class<?> currentClass,
>>>                                              Class<?> memberClass,
>>>                                              Class<?> targetClass,
>>>                                              int modifiers)
>>>     {
>>
>> Where does this method exist?
>
> In jdk.internal.reflect.Reflection.
>
>
> Regards, Peter
>