There are several caller-sensitive methods in the JDK e.g. Class.forName(String) and ResourceBundle.getBundle that uses the caller to perform the relevant operation. For example, Class.forName(String cn) is equivalent to Class.forName(cn, true, currentLoader) where currentLoader is the caller's class loader.

For dynamic generated bytecode (bytecode instrumentation or dynamic language runtime) calling Class.forName or ResourceBundle.getBundle on behalf of a caller, this will get a wrong immediate caller.   Groovy and Grails circumvent this problem by calling a private sun.reflect.Reflection.getCallerClass(int depth) to walk the stack trace to skip its runtime stack frames and look for the true caller and call the API with the proper context (ClassLoader in most cases).  Such workaround may impose some subtle issue.  If the language runtime has a different privilege level than the script, you can get confusion about which privilege level is supposed to apply to the requested class name resolution.

Grails uses JVMTI to modify classes (springloaded runs as an agent implementing ClassFileTransformer).  java.lang.instrument.Instrumentation seems to be a proper place to ask JVM to skip new frames added due to instrumentation so that the caller-sensitive methods can look up the appropriate caller.

Further investigation may propose the new API in a different component.