JEP 176: Mechanical Checking of Caller-Sensitive Methods
Jeroen Frijters
jeroen at sumatra.nl
Sat Mar 2 11:27:54 UTC 2013
Remi Forax wrote:
> I've always found that getCallerClass() was done at the wrong side of
> the problem, i.e. asked inside the callee instead of being inserted at
> callsite.
Yes, I agree and in fact in the IKVM implementation a CallerID parameter is added to each method that has the HasCallerID annotation. The reason for the CallerID abstraction instead of simply passing a Class is performance. Constructing a Class is expensive on IKVM (and was even more expensive back when CallerID was introduced) and in many cases caller sensitive methods are only sometimes caller sensitive, so I want the class construction to be lazy. It's also possible to return the ClassLoader without actually constructing the class.
>From the .NET side an IKVM HasCallerID method looks something like this:
public class Class
{
[EditorBrowsable(Never)] // hide from .NET IDEs
public static Class forName(String name, CallerID callerID) { ... }
public static Class forName(String name)
{
return forName(name, CallerID.create(new StackFrame(1)));
}
}
The Java compiler calls the method with the explicit CallerID parameter and .NET code can simply call the other method.
Regards,
Jeroen
More information about the core-libs-dev
mailing list