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

Reply via email to