On 07/10/2012 10:07 PM, Jochen Theodorou wrote: > Hi all, > > assuming you have to compile code with indy that realizes this: > > Class.forName(x) > > Meaning, we want to execute forName from Class using invokedynamic. If > you then have frames in your trace looking like this: > >> java.lang.Class.forName0(Native Method) >> java.lang.Class.forName(Class.java:186) >> java.lang.invoke.MethodHandleImpl$GuardWithCatch.invoke_L2(MethodHandleImpl.java:1130) >> org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:680) >> groovy.util.JavadocAssertionTestSuite.<clinit>(JavadocAssertionTestSuite.groovy:71) > then it is clear to me, why it is failing. At least the Indyinterface > part, if not even the GuradWithCatch part are disturbing the stack > walking Class#forName is using. > > has anyone any idea on how to make this work across JVMs? One version, > that sounds quite crazy to me, but may just work, is to compile a helper > method on the class, that directly calls Class#forName and thus making > it work, since there is no longer a wrong stack frame at the position > Class#forName is looking for. But well... it may be a possibility > > bye Jochen >
Class.forName(name) is equivalent to Class.forName(name, true, lookup.lookupClass().getClassLoader()) As true and lookup.lookupClass().getClassLoader() are constant in the BSM, you can bound them using insertArguments. Rémi || _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
