On 14/12/2016 8:15 PM, Alan Bateman wrote:
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.
Yes - thanks Alan. I've only just noticed that setAccessible has been
updated to check the accessibility and throw an exception! That came as
a surprise. It doesn't have all the info needed to make the decision in
all cases.
David
-----
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
