magic reflection access checks

Christian Thalinger twisti at
Tue Aug 21 14:07:22 PDT 2007


While implementing the HotSpot interface (jvm.cpp) in CACAO and getting
the tricks used in HotSpot (damn, that is a hard job), I'm now stuck at
the magic access checks, like in:


The problem comes with reflection.  The generated accessor classes, like
sun/reflect/GeneratedConstructorAccessor1, get loaded and are a
sub-class of sun/reflect/MagicAccessorImpl.  Thus the access checks
grant them access to everything:

  // New (1.4) reflection implementation. Allow all accesses from
  // sun/reflect/MagicAccessorImpl subclasses to succeed trivially.

The problem I now have in CACAO is, I have to check if the currently
loaded class is a sub-class of sun.reflect.MagicAccessorImpl.  This
check can only be done when the super-classes get resolved.  But when
resolving the super-classes, the access-check functions of CACAO are
called (obiously, otherwise this would be a security hole) and these do:

    if (class_issubclass(referer, class_sun_reflect_MagicAccessorImpl))
        return true;

I can't do sub-class tests without the class being resolved doing the
check on.

My question is now, how does HotSpot handle this case?  How can HotSpot
do sub-class tests with a not-resolved class?

- twisti

More information about the hotspot-dev mailing list