Am 30.07.2013 14:17, schrieb Peter Levart: [...] > So what would give Groovy or other language runtimes headaches when all > there was was a parameter-less getCallerClass() API? Aren't the > intermediate frames inserted by those runtimes controlled by the > runtimes? Couldn't the "surface" runtime-inserted methods capture the > caller and pass it down? I guess the problem is supporting calling the > caller-sensitive methods like Class.forName(String) and such which don't > have the overloaded variant taking caller Class or ClassLoader as an > argument...
Speaking for Groovy... those intermediate frames are runtime controlled, yes, but passing down the caller class is exactly the problem. Imagine I would suggest that each and every method definition in Java automatically gets an additional parameter for the caller class, just to have access to it inside the method. You would not accept that for Java, would you? And so we cannot accept that for Groovy if we want to keep integration with Java... and the good integration with Java is one of the key points of Groovy. Even if we make something like that @CallerSensitive and add the parameter only in those cases, we break being able to override methods. Plus, before Groovy3 is not done we have to support several call paths. And the oldest one, which is still a fallback, does not support transporting the caller class through the runtime layers at all. Changing here is a breaking change. > John Rose suggested to "capture" the caller in the "surface" method and > bind it with a MethodHandle and then pass such MH down the runtime API > and finally call that method via MH. Only that you then need a java7+ only version, plus the already mentioned problem, that not all of the three general call paths support that or can be changed in a way to enable that without breaking user code. bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev