Hi,
May I answer this one...
On 06/04/2016 02:59 AM, Jochen Theodorou wrote:
On 03.06.2016 22:20, Alex Buckley wrote:
[...]
There's a clear contrast between the two-way check performed by the JVM,
and the one-way check (exports only, readability "for free") performed
by Core Reflection.
so... odes reflection code still produce runtime helper classes for
invocation? That is then a dynamic module based solution?
bye Jochen
Reflection code (Method.invoke, Field.[get|set],
Constructor.newInstance) are @CallerSensitive methods. They "know" which
class is calling them and perform access checks on behalf of the caller
class that are "equivalent" (with mentioned exceptions) to what JVM does
when it resolves various invoke / [get|put]field bytecodes. You may peek
into sources to see what they do. In the end they invoke the method
using either JNI or bytecode generated accessor classes which are free
from access checking and access the fields using Unsafe which is free of
access checking too. So reflection does access checks on every access
and has its own logic written in Java to perform them which uses an
internal cache (see AccessibleObject.checkAccess / securityCheckCache).
Bytecode instruction access checks are performed lazily by JVM which is
very good at optimizing them "away" so they don't affect performance.
So your question was about runtime helper classes for invocation. Yes,
this has not changed. And the trick is that these generated helper
classes all extend a special internal class:
package jdk.internal.reflect;
/** <P> MagicAccessorImpl (named for parity with FieldAccessorImpl and
others, not because it actually implements an interface) is a
marker class in the hierarchy. All subclasses of this class are
"magically" granted access by the VM to otherwise inaccessible
fields and methods of other classes. It is used to hold the code
for dynamically-generated FieldAccessorImpl and MethodAccessorImpl
subclasses. (Use of the word "unsafe" was avoided in this class's
name to avoid confusion with {@link jdk.internal.misc.Unsafe}.) </P>
<P> The bug fix for 4486457 also necessitated disabling
verification for this class and all subclasses, as opposed to just
SerializationConstructorAccessorImpl and subclasses, to avoid
having to indicate to the VM which of these dynamically-generated
stub classes were known to be able to pass the verifier. </P>
<P> Do not change the name of this class without also changing the
VM's code. </P> */
class MagicAccessorImpl {
}
Regards, Peter
