question on exports to

[Peter Levart]

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