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

[Peter Levart]

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

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