magic reflection access checks

[Christian Thalinger]

Hi!

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:

Reflection::verify_class_access

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